Full Scale Lab 3 - 2.4 OSPF Routing

 

Hello,

I found this task quick challenging and fun to think about. It did take around 1 hour to formulate a solution. In the real lab, it would be game over! My solution is different the one provided in the SG, is not as "clean", but I believe it achieves the requirements and doesn't appear to cause any problems later on down the track.

 

The problem is that of OSPF path selection (namely intra-area routes being preferred over inter-area) and we have to do traffic engineering to work around this fact.

My solution was to first filter out the prefixes from entering the RIB on R11 and R14. At this stage the LSAs are still present in the database and they will be advertised to other neighbors but they won't enter the RIB on R11 and R14:


p { margin-bottom: 0.1in; line-height: 120%; }

 

!
R11

ip
prefix-list R14-LOOP seq 5 deny 150.1.14.14/32

ip
prefix-list R14-LOOP seq 10 permit 0.0.0.0/0 le 32

!

router
ospf 1


distribute-list
prefix R14-LOOP in Ethernet0/1.411


p { margin-bottom: 0.1in; line-height: 120%; }

 

!
R14

ip
prefix-list R11-LOOP seq 5 deny 150.1.11.11/32

ip
prefix-list R11-LOOP seq 10 permit 0.0.0.0/0 le 32

!

router
ospf 1


distribute-list
prefix R11-LOOP in Ethernet0/1.1214

 


The next step was to prevent these routers from translating and generating Type-3 (Summary) LSAs for these two prefixes into Area 0. This step is technically not required, but it allows for a cleaner routing table on the other OSPF routers in Area 0 (they won't have both the /32 and /31):

 


p { margin-bottom: 0.1in; line-height: 120%; }

!
R11 & R14

ip
prefix R11-R14-LOOP deny 150.1.11.11/32

ip
prefix R11-R14-LOOP deny 150.1.14.14/32

ip
prefix R11-R14-LOOP permit 0.0.0.0/0 le 32

!

router
ospf 1


area
0 filter prefix R11-R14-LOOP in

 

And now on R11 and R14 we generate a summary address in Area 0. I choose a summary mask of /23:


p { margin-bottom: 0.1in; line-height: 120%; }

 

!
R11

router
ospf 1


area
1000 range 150.1.11.10 255.255.255.254

 

!
R14

router
ospf 1


area
1000 range 150.1.14.14 255.255.255.254

 

The final result is that R11 and R14 are reaching each other over the e0/1.114 link:


p { margin-bottom: 0.1in; line-height: 120%; }

 

!
R11

sh
ip cef 150.1.14.14

150.1.14.14/31


nexthop
10.254.255.7 Ethernet0/1.1114

 

sh
ip ro | s 14.14

O
IA 150.1.14.14/31


[110/10001]
via 10.254.255.7, 00:08:01, Ethernet0/1.1114

 

It's worth noting that performing summarisation of the loopback addresses of routers which may be used as MPLS PE nodes is fraught with danger and carries a high risk of "breaking things" later on. Luckily, in this case neither R11 or R14 were performing the roles of PEs later on in the lab.

 

Thoughts? A valid solution or not?

Comments

  • It works...I dont see you violating any of the restrictions. I would consider this a valid answer - although it was not was the task is particularly "looking" for [:P]

    The scenario was set up mainly to discuss the particular traffic engineering problem which this design yields, and to introduce the solution discussed in the solution guide (dont want to spoil it for others who have not done it yet). In this corner case your solution does in fact accomplish the goal, but had R14 or R11 been PE devices then as you mentioned this would have not worked.

    Great way to get creative!

     

  • It works...I dont see you violating any of the restrictions. I would consider this a valid answer - although it was not was the task is particularly "looking" for [:P]

    The scenario was set up mainly to discuss the particular traffic engineering problem which this design yields, and to introduce the solution discussed in the solution guide (dont want to spoil it for others who have not done it yet). In this corner case your solution does in fact accomplish the goal, but had R14 or R11 been PE devices then as you mentioned this would have not worked.

    Great way to get creative!

     

  • Hi

     

    First, you did a nice job to resolve this task! 

     

    Regarding the SG solution, I'm not sure if they are violating the "Dont": "Do not... change OSPF area boundaries to accomplish this task."

     

    In my opinion extending Area 1000 over an additional interface mean changing the area 1000's boundary, no?

     

    Just not sure how to interpret this "Dont". 

     

    Any thought?

     

Sign In or Register to comment.