Again JNCIP ISIS Case studies

Robert_74

Just went through JNCIP ISIS case studies and was quite surprised in the end: as soon as level 1 preference on R6 and R7 changes to 155, one of the ISIS routers ( either R6 or R7 - depends on where change goes first) makes preference to 0.0.0.0 over OSPF, and that makes perfect sense for me for ospf has 150.

Rather an elusive explaination in the book just stated somethng like change preference after redistribution, and that is it. I have checked already more then 10 times trying to figure it out but still got the same result.

Has anyone noticed the same, by chance ??

Thanks

Robert

hoogen82

What's the issue here, I haven't understood your question...

Yes the Case Study asks you to change the level 1 preference to 155. This would indeed make OSPF's default route a preferred one...

The above requirement is intentional, so that you are made to make some more changes and get the default route back to be preferred by ISIS... You need to write a policy when redistributing from OSPF to ISIS to deny the redistribution of the default route (This is not that important) and also change the OSPF external preference to 159.. The external preference will make the routers prefer ISIS def again..

Robert_74

OK, I see you do not understand. Let me explain

1) We redistribute isis default from both R6 and R7. Out external router is happy to have two defaults, as per requirement

2) Now we change preference to 155 on both R6 andR7. It results to:
- R7 has only ISIS default and can forward traffic to R1 and R2
- R6 has two defaults, one received from OSPF ( R7 default) and another one generated based on A bit from R5
- external router has only one default towards R7
- when R6 wants to get to R1 or R2, it follows OSPF default, so the path becomes R6-external-R7-R5 and so on
- if subnet between R6 and external not in ISIS, then you can reach R1 and R2 from R6, unless you use source address reachable from R1 or R2

So, I do not believe this is the desired behaviour. It works, but from optimal path.
You suggest :
..You need to write a policy when redistributing from OSPF to ISIS to deny the redistribution of the default route .. --- we do not redistribute default from OSPF, we redistribute default from ISIS
.. changing OPSF external preference to 159 - what's the point ?? The only reason for increasing preference to 155 in ISIS is to make it bigger then OSPF, this is where the trick is

Robert_74

sorry, this part should be read as "..if subnet between R6 and external not in ISIS, then you can not reach R1 and R2 from R6 "

hoogen82

I did say the first solution was not important, but suggested in the book. Also it just adds as a safety from future def route injection in the lab if any... It's just a safety but not important

The Subnet between R6-DC is represented can be represented as a route from OSPF with a route-filter to match routes 172.16.40/29 longer and redistributed into ISIS... It solves our purpose of having reachability to these subnets.

The point is there is no way you can have an import policy to deny routes you receive from a OSPF neighbor, so you would get the def route on your routers connected to DC.

The case study doesn't tell us that we can't use/change the preference of the OSPF external routes. By changing them to be higher than 155 we are able to get the ISIS def preferred again. Now we keep it to a value lower than 160 since we have the ISIS level1 (160) externals (192.168/21 longer) routes being redistributed from OSPF to ISIS.

HTH
Hoogen