02-25-2014 01:40 PM - edited 03-04-2019 10:26 PM
Hi Guys,
Got another one for ya.
R4-----------------------------------------------R5
| |
OSPF1 | | OSPF1
----------------R2 R3--------------------
EIGRP1 | | EIGRP1
|------------------------R1------------------------|
|
|
R6
192.168.253.0/24
Learned by R6 via external downstream EIGRP route (AD 170)
R2 & R3 are doing two-way redistribution:
R2:
router eigrp 1
redistribute ospf 1 metric 10000 100 255 1 1500
router ospf 1
redistribute eigrp 1 subnets
R3:
router eigrp 1
redistribute ospf 1 metric 10000 100 255 1 1500
router ospf 1
redistribute eigrp 1 subnets
Now, R3 tries to ping 192.168.253.0/24. However, because R2 & R3 are both doing two-way redistribution, we have a loop, since R1 will prefer the OSPF route for 192.168.253.0/24 because the AD is 110, versus R6's external EIGRP route for 192.168.253.0/24, which is 170. So we will end up going in a circle until the TTL expires.
I'm told the recommended solution for this is to implement route-maps and tags on R2 & R3, preventing the far-end redistributor's route tag & permitting it's own as such:
R2:
route-map EIGRP-into-OSPF deny 10
match tag 333
route-map EIGRP-into-OSPF permit 20
set tag 222
route-map OSPF-into-EIGRP deny 10
match tag 333
route-map OSPF-into-EIGRP permit 20
set tag 222
router eigrp 1
redistribute ospf 1 metric 10000 100 255 1 1500 route-map OSPF-into-EIGRP
router ospf 1
redistribute eigrp 1 subnets route-map EIGRP-into-OSPF
R3:
route-map EIGRP-into-OSPF deny 10
match tag 222
route-map EIGRP-into-OSPF permit 20
set tag 333
route-map OSPF-into-EIGRP deny 10
match tag 222
route-map OSPF-into-EIGRP permit 20
set tag 333
router eigrp 1
redistribute ospf 1 metric 10000 100 255 1 1500 route-map OSPF-into-EIGRP
router ospf 1
redistribute eigrp 1 subnets route-map EIGRP-into-OSPF
So now R2 denies R3's redistributed route information and R3 denies R2's redistributed route information. This resolves the loop.
But here's the problem I have with this:
When R3 tries to ping 192.168.253.0/24, it still takes the path through OSPF (R3-R5-R4-R2-R1-R6) instead of taking R3-R1-R6.
How can this happen if R3 is denying R2's "222" tagged routes? R3 shouldn't have any knowledge of the external OSPF route to 192.168.253.0/24 because I'm blocking it by denying R2's tags.
Solved! Go to Solution.
02-25-2014 02:33 PM
Hi,
your are wrong here: "R3 shouldn't have any knowledge of the external OSPF route to 192.168.253.0/24 because I'm blocking it by denying R2's tags."
You are only blocking prefixes tagged by redistribution on R2 to be redistributed again on R3.
But R3 still accepts them into his RIB!
IMHO, you should also change your tagging scheme:
You shouold not redistribute on any router any prefix which was redistributed already.
So
R2:
route-map EIGRP-into-OSPF deny 10
match tag 333
route-map EIGRP-into-OSPF permit 20
set tag 222
!
route-map OSPF-into-EIGRP deny 10
match tag 222
route-map OSPF-into-EIGRP permit 20
set tag 333
And the same on R3.
But this will still not fix your problem, I'm afraid.
You would need to stop redistributing EIGRP external routes into OSPF on R2.
Best regards,
Milan
02-25-2014 02:33 PM
Hi,
your are wrong here: "R3 shouldn't have any knowledge of the external OSPF route to 192.168.253.0/24 because I'm blocking it by denying R2's tags."
You are only blocking prefixes tagged by redistribution on R2 to be redistributed again on R3.
But R3 still accepts them into his RIB!
IMHO, you should also change your tagging scheme:
You shouold not redistribute on any router any prefix which was redistributed already.
So
R2:
route-map EIGRP-into-OSPF deny 10
match tag 333
route-map EIGRP-into-OSPF permit 20
set tag 222
!
route-map OSPF-into-EIGRP deny 10
match tag 222
route-map OSPF-into-EIGRP permit 20
set tag 333
And the same on R3.
But this will still not fix your problem, I'm afraid.
You would need to stop redistributing EIGRP external routes into OSPF on R2.
Best regards,
Milan
02-25-2014 02:43 PM
Dean
However, because R2 & R3 are both doing two-way redistribution, we have a loop, since R1 will prefer the OSPF route for 192.168.253.0/24 because the AD is 110, versus R6's external EIGRP route for 192.168.253.0/24, which is 170. So we will end up going in a circle until the TTL expires
I am a bit confused about this as your diagram shows R1 is not running OSPF only EIGRP. So all routes learnt via EIGRP will be AD 170 ie. there should be no route on R1 with an AD of 110 because there is no OSPF.
So i don't think that is the reason for your loop.
How can this happen if R3 is denying R2's "222" tagged routes? R3 shouldn't have any knowledge of the external OSPF route to 192.168.253.0/24 because I'm blocking it by denying R2's tags.
R3 is not redistrbuting routes learnt from R2 back into EIGRP but it still receives the OSPF routes from R2, it just doesn't redistribute them back into EIGRP.
So R2 redistributes the 192.168.253.0/24 network into OSPF. R3 receives this but does not redistribute it back into EIGRP. So from R3's perspective it has two routes for this -
1) OSPF external route received from R2 with an AD of 110
2) EIGRP external route received from R1 with an AD of 170
so R3 will always choose the OSPF route because it has a a lower AD and so is the route in the IP routing table.
You can check this with a "sh ip route 192.168.253.0 255.255.255.0" on R3 and you should see it is the OSPF route.
There is nothing you can do to make it prefer the R1 direct route in terms of how you filter route redistribution because OSPF external will always be chosen over EIGRP external.
You would need to change AD of EIGRP external routes for this to work.
Edit - just seem Milan's post. You could also not do redistribution on R2 as suggested but i assumed you wanted to redistribute on both routers.
Jon
02-26-2014 01:06 AM
Hi Jon,
I was also thinking about changing the AD of EIGRP external routes.
But where?
On R3?
Would'n EIGRP external routes include also those redistributed from OSPF by R2 then?
So we would need to change the AD of one (or several) particular prefixes only, I guess?
Possibly something like this might be a solution:
Just decreasing the AD for 192.168.253.0/24 prefix received by EIGRP from R1 to 91 on R3?
Best regards,
Milan
02-26-2014 09:27 AM
Hi Milan
Yes on R3. I was thinking specifically of 192.168.253.0/24 prefix to make R3 always prefer the link via R1.
You are right though if R2 was redistributing you would have to do based on the advertising router which you can based on that link you sent.
Jon
02-26-2014 12:23 PM
Hi Jon / Milan,
Firstly, thank you for clarifying why the sub-optimal path is still preferred. I understand that now. I should also mention that this is a lab to reinforce concepts. I would avoid something like this at all costs. That said, I do have a solution that would solve both the loop and the sub-optimal path, but I'll get to that later.
I have questions for both of you on your follow up answers:
Milan,
Could you elaborate more on why the tagging scheme should be changed? I'm trying to follow the logic as you've configured it but it is really confusing me having the tags reversed from each other on each route-map within the same router. The way I was understanding it in my config example was:
R2:
route-map EIGRP-into-OSPF deny 10
match tag 333
route-map EIGRP-into-OSPF permit 20
set tag 222
route-map OSPF-into-EIGRP deny 10
match tag 333
route-map OSPF-into-EIGRP permit 20
set tag 222
What this says to me:
"Do not redistribute any of R3's external routes with a tag of 333 from EIGRP into OSPF. Redistribute EIGRP routes with a tag of 222 (i.e. sourced from R2) into OSPF."
"Do not redistribute any of R3's external routes with a tag of 333 from OSPF into EIGRP. Redistribute OSPF routes with a tag of 222 (i.e. sourced from R2) into EIGRP."
To summarize: R2 should redistribute only routes with a tag of 222
R3:
route-map EIGRP-into-OSPF deny 10
match tag 222
route-map EIGRP-into-OSPF permit 20
set tag 333
route-map OSPF-into-EIGRP deny 10
match tag 222
route-map OSPF-into-EIGRP permit 20
set tag 333
What this says to me:
"Do not redistribute any of R2's external routes with a tag of 222 from EIGRP into OSPF. Redistribute EIGRP routes with a tag of 333 (i.e. sourced from R3) into OSPF."
"Do not redistribute any of R2's external routes with a tag of 222 from OSPF into EIGRP. Redistribute OSPF routes with a tag of 333 (i.e. sourced from R3) into EIGRP."
To summarize: R3 should redistribute only routes with a tag of 333.
Is this logic not correct?
Jon,
I'm with you on the fact that R3 will prefer the external OSPF route to 192.168.253.0/24 since the AD is 110 vs AD of external EIGRP at 170. So the path is R3-R5-R4-R2-R1.... Now here's the part where I get confused - when the traffic hits R1, which as you said correctly, is only running EIGRP. My text says when the traffic reaches R1, R1 forwards it back to R3 as opposed to down to R6.
But I see what you're saying; When the traffic gets to R1, R3 is going to say "Hey, I have an external route to 192.168.253.0/24 and it'll cost you 170 to ride it," and R6 is saying the exact same thing. So I guess the answer would lie in whatever tie-breaking mechanism exists to explain the loop (i.e. tie-breaker is in favor of R3 every time). I was originally thinking R1 would see the advertisement from R3 for 192.168.253.0/24 as OSPF 110 because that's how R3 sees it, but what you say makes sense. The book doesn't specify if a tie breaker is used, and it's driving me nuts. Let me type the paragraph word for word to see if it helps point out the loop culprit to you:
"R3 prefers the 192.168.253.0/24 route advertised by OSPF instead of EIGRP because the routes redistributed into OSPF on R2 have a lower AD than the external EIGRP route advertised by R1."
I'm fine with that part.
"Because R3 prefers the 192.168.253.0/24 route received via OSPF, when mutual redistribution is configured between EIGRP and OSPF on R3, these same routes will be redistributed into EIGRP and readvertised back into the EIGRP domain. Because of this behavior, a routing loop has been created."
That's the part I'm not understanding.
02-26-2014 01:17 PM
Dean
It's difficult without being able to test it or without seeing the full context of the book to say exactly what is happening.
However R1 receives a route advertisement for 192.168.253.0/24 from both R3 and R6. They are both EIGRP external so the tie breaker is the metric associated with each route.
I can only assume the metric received from R3 is better than R6 so R1 chooses to forward traffic back to R3 instead of to R6.
So from R3 a ping to a 192.168.253.x device would go via the OSPF routers (R5/R4/R2) to R1 who then forwards it back to R3 and round you go again.
Jon
02-27-2014 02:30 AM
Hi Dean,
well, the difference is following:
You are tagging the prefixes while redistributed on each router. And denying the tagged prefixes to be redistributed again on the other router.
I'm tagging the prefixes while redistributing from one routing protocol to the other. And denying the tagged prefixes to be redistributed again on any router.
So:
When your R2 is redistributing any prefix (to any protocol) it taggs it with 222.
When R3 is redistributing an prefix (to any protocol) it taggs it with 333.
And both don't redistribute any prefix tagged by the other router already.
When I redistribute any prefix from EIGRP to OSFP, I tagg it with 222 (on any router).
When I redistribute any prefix from OSPF to EIGRP, I tagg it with 333 (on any router).
And I don't redistribute any prefix which had been redistributed already by matching the tags.
I believe my scheme is a little safer in topologies with more routers involved:
a) I can use the same route-map on all routers
b) It also denies the prefixes received from some third router but redistributed by my router itself originally.
But both tagging schemes should work in your case.
So you don't need to change it, I should have said "It might be easier to use...".
Best regards,
Milan
02-27-2014 07:58 AM
Jon,
I see what you're saying. Makes sense. Though I do wish the book would specify further
As always, I appreciate your help and insight.
Milan,
I see. So, R2 will redistribute EIGRP into OSPF with tag 222 & OSPF into EIGRP with tag 333. What happens though when R3 advertises it's external routes to R2? Won't R2 "re-redistribute" R3's external routes, respective to the tags permitted for each route-map?
In other words, if R2 receives a route from R3 with tag 222, for example, won't it consult it's route-map for EIGRP-into-OSPF and see that only tag 333 is denied, ultimately re-redistributing the tag 222 route since it's not in the deny sequence list?
Now to the potential solution to address the loop and the sub-optimal routing:
R2:
route-map DENY-EXTERNAL-FROM-R3 deny 10
match tag 333
match route-type external
route-map DENY-EXTERNAL-FROM-R3 permit 20
match tag 222
match route-type external
route-map DENY-EXTERNAL-FROM-R3 permit 30
route-map FILTER-REDISTRIBUTE permit 10
set tag 222
router ospf 3
distribute-list DENY-EXTERNAL-FROM-R3 in
redistribute eigrp 1 subnets route-map FILTER-REDISTRIBUTE
router eigrp 1
distribute-list DENY-EXTERNAL-FROM-R3 in
redistribute ospf metric 10000 100 255 1 1500 route-map FILTER-REDISTRIBUTE
R3:
route-map DENY-EXTERNAL-FROM-R2 deny 10
match tag 222
match route-type external
route-map DENY-EXTERNAL-FROM-R2 permit 20
match tag 333
match route-type external
route-map DENY-EXTERNAL-FROM-R2 permit 30
route-map FILTER-REDISTRIBUTE permit 10
set tag 333
router ospf 3
distribute-list DENY-EXTERNAL-FROM-R2 in
redistribute eigrp 1 subnets route-map FILTER-REDISTRIBUTE
router eigrp 1
distribute-list DENY-EXTERNAL-FROM-R2 in
redistribute ospf metric 10000 100 255 1 1500 route-map FILTER-REDISTRIBUTE
My logic for this solution is:
R2:
Deny all external routes with tag 333
Permit all external routes with tag 222
Permit all other routes
Set tag 222 in route-map for redistribution statement.
R3:
Deny all external routes with tag 222
Permit all external routes with tag 333
Permit all other routes
Set tag 333 in route-map for redistribution statement.
On both router, on both routing protocols, configure distribute-list calling "DENY-EXTERNAL-FROM-RX" inbound. On all redistribute commands, call route-map FILTER-REDISTRIBUTE.
Wouldn't this address the sub-optimal routing path from R3-R1 as well as preventing the loop successfully?
02-27-2014 09:03 AM
Hi Dean,
yes, it's safer also to deny the prefixes redistributed by the router itself originally within the route-map used for redistribution.
I just reviewed the design I've done several years ago when I had to use something similar in my network and I was doing so.
But your solution presented here would decrese the redundancy in your network, I'm afraid.
As the distribution lists on R3 would drop all the prefixes redistributed by R2 and vice versa.
I still believe changing the AD of external EIGRP prefixes (like 192.168.253.0/24) recievd from R1 on R2 and R3 would be the solution.
Or you might use another tag for external EIGRP prefixes received from R6 on R1 and macth it on R2 and R3 possibly?
Best regards,
Milan
02-28-2014 02:30 PM
Thanks Milan.
Well the thing is, with the distribute lists I configured, my thought process is basically that; if I lose R2, for example, the the redistribution will still occur via R3, because with the distribute lists and the route maps, each router is kind of acting like they are the only ones redistributing anyway, right? Then when R2 recovers, it will start redistributing again, still independent of the fact the R3 is redistributing and vice-versa, and traffic will end up taking withever router has the better metric (i.e. based on port bandwidth, delay, etc....).
The thing I am afraid of with changing the AD of EIGRP is what if this situation was reversed? I.E. - What if 192.168.253.0/24 was on the OSPF side? Wouldn't we have the same problem but in the reverse, making changing the AD of EIGRP moot? And I suppose in that case we could just change the AD of OSPF, but in what I would consider the most realistic scenario would be a subnet of interest on the EIGRP domain (i.e. like 192.168.253.0/24) AND a different one on the OSPF domain. In that case, I don't think we could solve this by modifying AD's.
03-02-2014 01:04 AM
Hi Dean,
I'm afraid you would loose some redundancy with your distribute list applied.
Imagine following scenario:
The line between R1 and R3 fails.
R2 is still redistributing 192.168.253.0/24 into OSPF but your distribute list is blocking it on R3.
So you will loose your connectivity from R3 to 192.168.253.0/24 in that case.
Regarding the EIGRP external route AD change on R3 I suggested:
is showing how to change AD for some external EIGRP prefixes only, not all of them.
IMHO, that's exactly what you need: To change the AD of 192.168.253.0/24 EIGRP external route on R3.
I don't see any problem with some subnets of interest in OSPF cloud:
OSPF prefixes (also external ones) are preferred over EIGRP external ones on R2 and R3 by default.
Best regards,
Milan
03-05-2014 10:12 AM
Hi Milan,
Yeah you are right. I hadn't thought of the failure occurring there. That would certainly cause issues. I guess the AD change is the only solutions.
Thanks for all your help on this. Very much appreciated.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide