IEOC - Internetwork Expert's Online Community

So the ording on the last bullet for Task 2.2 states:

• R5 should still be able to reach this prefix if the Frame Relay circuit
  between R2 and R3 is down.

I assume that "this prefix" is refering to the 204.12.1.0/24 and 183.1.39.0/24 subnets that were added earlier in the task. 

Now, the solution guide states that you need to modify the connected-eigrp route-map in order to still reach those subnets when the FR link between R2 and R3 is broken....but I dont see that as being right.  If the FR link is down then R3 has lost connectivity to the EIGRP domain, so why would I want to redistribute the serial link for the OSPF domain into eigrp ??  Makes no sense...

Wouldnt you have to redistribute connected to OSPF and advertise the afformentioned subnets into OSPF ??

I'm sure I'm confused here....can someone help ???

Hi, ..

Totally agree to You, the SG shold be updated to clarify this.

Looks like this Section in the Lab has been modified from V4.1 to V5, but the section in the SG has not, it is still the one from V4.1

My suggestion for R3 is to redistribute connected without a route-map under ospf and eigrp ( as it is mentioned in the SG ).

The two prefixes should appeear as EX, so You have to red connected into EIGRP. This would point to using a route-map with red connected

When it comes to redistribution between EIGRP and OSPF, the route-map prevents the "connected" networks ( prefixes with network x.x.x.x under "router ospf" )

from being redistributed into EIGRP. To accomplish this, You have to add the missing prefixes to this route-map or use the red connected without the route-map.

Cheers, ..

/Christian

I've been toiling over this exact issue for the last 2 hours.  I'm come to the conclusion that there is no reason given the initial configs or through any of the tasks that 183.x.39.0/24 or 204.12.x.0/24 would be advertized in ospf to R5 from R3.  Therfore if the R2-R3 link fails, R5 cannot know about those prefixes.  You would have to explictly include that networks in ospf or redistribute the connected routes to ospf to get the routes over to R5.

Maybe the thought was that you could redistribute CONNECTED to EIGRP, then EIGRP to OSPF, and the CONNECTED routes would end up in OSPF, but that doesn't appear to be the case, at least not for me and the IOS versions I'm using.

Seems crazy to me that through all the meets-up and all the people doing these labs that there are still mistakes and bad wording in these.

*Maybe the thought was that you could redistribute CONNECTED to EIGRP, then EIGRP to OSPF, and the CONNECTED routes would end up in OSPF, but that doesn't appear to be the case, at least not for me and the IOS versions I'm using.*

This is how redistribution works.  if you redistribute protocol A into porotcol B, then Protocol B into Protocol C, the A routes redistributed into B will not be advertised by C. 

When you redistribute, the router logic is a two step process:

1:  Grab all (protocol type being redistributed) routes in the routing table.  ex.  RIP>OSPF  show ip route rip - those routes will go to OSPF

AND

2. Grab the subnets of the interfaces that the routing protocol being redistributed is running on.

Point 2 can (and will) break if you redistribute connected with a route map that omits the interfaces that the protocol is running on.  

I know its confusing and maybe I'm not stating it with the easiest verbage, but there is a great video about this in the class on demand product the IE sells.

That was very helpful, thank you.  It was a good explaination.  We still have the main issue here of getting the CONNECTED routes into OSPF.  Remember that EIGRP is not running on those interfaces, so redistributing EIGRP->OSPF will not get those prefixes advertised into OSPF.

I could be worng but I'm pretty sure there is a mistake in the Lab there.  Based on the intital configs and the tasks it seems the prefixes can't get into OSPF, so if that R2-R3 link fails R5 will not have reachablility to those interfaces on R3.

I had to redistribute CONNECTED into OSPF to get the result they were looking for.  I look forward to the Lab Meetup to see how this is supposed to be handled.

yeah....I basicaly decided that something was lost in translation when it came to this question.  I moved on....

By the way, your name is hillarious....Spongeworthy....HA !!!

This solution by INE is as flawed as an ashtray on a motorbike..

The fact that R5 is hard-coded to reach R1's lo0 via ospf means if the link between R2 and R3 is down the packets are black holed. Also R3 and R5 are both redistributing normally which will cause loops.

you know....I was wondering about the normal mutual redistribution.  I set tags on the redistributed routes and filtered on those tags, but it wasnt mentioned anywherein the solutions.  I thought I was missing something as far as the AD of the 2 protocols was concerned....I didnt poke any farther cause my setup worked without loops.....oh well....it is what it is......

Thanks for kinda validating what I had suspected......anyone else have any other input on this ????

Tagging is probably the best method i think..

I suppose since its Lab 1 the guys did not want to mention the fact that there could be resultant loops. However by not mentioning, it causes questions to be raised. Arrhh this whole lab is spoit by this task because it causes more problems later in BGP. I personally have decided to move away from this because I think spending time fixing a poorly designed lab is a waste of our valuable time.

They cleaned it up, Lab 1 has been complete cleaned up.  Re-download it.  Point taken that they shouldn't have post it like that to start with, it cost me hours and hours of worthless troubleshooting.

My strategy goin into the real lab is that any time there is mutual redistribution, tag and filter....no matter what....there are ways to prevent loops by messing with the AD of the protocols and ospf route types and whatnot....I'm gonna stick with what I know....tag and filter...

I switched from workbook 2 to workbook 1 for right now....workbook 1 is great...not perfect, but key if you want a solid understanding of the core and advanced topics...

I agree with the tagging. It's more scalable. It's more straightforward. It doesn't fail. You are more likely to see that deployed in a production environment vs. AD/metric tricks.