Going back to this above visualization of 2-way Redistribution which is a perfect case use for a Route-Map to perform “Route Tagging” for routes being Redistributed, which assigns tag # values to Routes as they Redistribute and can filter (drop) routes that contain a certain tag value to ensure routes are not re-learned into their origin Domain.
Creating a Route-Map for Route-Tagging in 2-way Redistribution
The first thing to remember is with Route-Maps in regards to Redistribution, is that a deny statement means “Do not redistribute the following criteria” whereas PBR means “Route traffic normally” with deny statements in the Route-Map.
I pulled this from a ROUTE Redistribution lab from years ago I ran, and wanted to use this example to review EIGRP / OSPF Redistribution Route-Tagging:
R1(config)#do sh route-map
route-map EIGRP2OSPF, deny, sequence 5
Match clauses:
tag 110
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map EIGRP2OSPF, permit, sequence 10
Match clauses:
Set clauses:
metric-type type-1
tag 100
Policy routing matches: 0 packets, 0 bytes
route-map OSPF2EIGRP, deny, sequence 10
Match clauses:
tag 100
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map OSPF2EIGRP, permit, sequence 15
Match clauses:
Set clauses:
tag 110
Policy routing matches: 0 packets, 0 bytes
R1(config)#
With this Route-Map after going through the previous Redistribution articles I can see a few things right away:
- The Metric from OSPF -> EIGRP will need to have the metric values (K Weights) manually set along with this route-map added into the statement, as the metrics are not defined in this route-map
- The Metric-Type for EIGRP -> OSPF is set to Type-1 in the Route-Map, meaning the non-deafult E1 OSPF External routes will be used as the “seed metric” which starts out as Metric value of 20 at the Boundary Router and increment as it is shared into the OSPF Routing Domain
- Each Both Route-Maps first statement is to “Deny” the tag value defined in the opposing Route-Maps tag set value, so that if the Route is being dropped from being re-learned back into its own domain, the device doesn’t need to use resources to look any further into the Route-Map at other sequences as its unnecessary
Note that ACL’s and Prefix-Lists can be used to define certain routes to have route-map clauses applied to, and this is where things may get tricky on exam day, as the ACL or Prefix-List defined might not contain the correct routes for the desired outcome.
I have plenty of labs geared toward Redistribution to view by clicking on the ROUTE – Redistribution segment or just searching “Redistribution” on this site.
Some other considerations for basic Route-Map troubleshooting:
- Is the correct Route-Map applied?
- Verify every sequence to understand its action, remember deny simply means “Do not Redistribute” in a Redistribution Route-Map, and at the end of each Route-Map is an implicit “Deny All” which means if no matches were found routes will not be Redistributed into the target protocol
- Verify any ACL or Prefix-List specified under the “match” clause to ensure the correct subnets with “permit” statements, as “deny” will just mean the specified network will not be impacted by the Route-Map and might as well not be in the ACL at all for the Route-Map (though this may be a tricksy Cisco gotcha on exam day)
- If a “Route-Map” is defined in a redistribute statement, it does not inherently mean that Route-map exists, so verify it exists with “sh route” command!
That about does it for Route-Maps and troubleshooting, I did want to jump into some logical methodology for troubleshooting Route Redistribution overall.
Redistribution Troubleshooting commands and considerations for exam day!
The following is first a list of things to check say if a Branch office is not seeing routes from its Boundary Router to reach destinations in another Routing Domain:
- Are the routes in my IP Route Table locally? “sh ip route”
- Are the routes in my Routing Process Table? “sh ip eigrp top” / “sh ip ospf data”
- Are my interfaces enabled for the protocol? “sh ip (protocol) int”
- Is there an adjacency between the Branch and Boundary Router? “sh ip (protocol) nei”
- Can I see the Boundary Router via CDP? “sh cdp nei (det)”
- Are the expected routes in the IP Route Table of the Boundary Router? (Must be in IP Route table to be Redistributed!) “sh ip route”
- Is Redistribution turned on (and with what parameters) on the Boundary Router? Are Filter Lists Set? Route-Maps used? “sh ip proto” to verify
- Are the Routes showing in the route processes on the Boundary Router? “sh ip eigrp top” / “sh ip ospf data” / Etc
- If EIGRP is in use, is a Metric being defined for Redistribution? Metric MUST be set for EIGRP Redistribution or the routes seed metric will be unreachable, verified in “sh ip proto” modifiers in redistribution segment (or in running-config)
If the Boundary Router does not have the expected route in its own Routing Process table, these things will need to be continued to be checked along the Data Path all the way to the the router the network is behind (and possibly its switched network).
An overview of issues that can be caused as a result of Redistribution
- Forgetting to add a Metric to routes being Redistributed into OSPF
- OSPF Internal Routes only redistribute into BGP by default, must manually add external / nssa routes
- “Subnets” command may be missing for discontiguous networks
- “Include-connected” may be missing from IPv6 Redistribution
- With two or more points of Redistribution, you will want to use the “distance” command to manipulate the Metric to be lower for a certain Boundary Router to make it the preferred Boundary Route path
- With two or more points of Redistribution, you will want to use “Route-Tagging” via route-map as described at the top of this post to prevent routes leaking back into their own Routing Domain – Make sure these route tags are configured via route-map on each Boundary Router redistribute statement!
- A more preferred route (lower AD) may be in the IP Route table, like a Static Route, that is not being Redistributed into the target Routing Domain
That will do it for Redistribution Troubleshooting and Theory!
I will conclude this Redistribution section with the lab that was initially configured to take a deeper look at Redistribution commands on the CLI, configuration of Redistribution, and behaviors / troubleshooting along the way – lab time!
The DEVNET GRIND! 