Saturday, November 15, 2014

OSPF Path Selection With Default Information Originate - How You Gonna Fix It ? - Part 1

I recently got a call from friend , he was stuck with an interesting OSPF Path Selection issue. Obviously the things didn't work the way he expected it to be :)

Now initially he was been given a Consulting task that involved Design & Configuration changes to meet a new network requirement.

Here is how the network initially looked like :


The customer had active-active WAN connections where these connections were also serving both WAN as well as Internet connectivity. Where as in LAN side they were using OSPF as shown in Topology above.

Now the new requirements given were:

> Brought Up New Internet Connection that will act as Primary Path to reach internet.

> In case the New Internet connection goes down, the old WAN cloud should still work as backup path to reach internet

> From R4's perspective, the path towards R2 should be primary path to reach internet (Through New Internet GW) while path through R3 should be backup path. I am not sure why this was a Hard Requirement but I guess the path from R4 to R3 was through RF link as shown below:




> Introduction of Static Routes, PBR, NAT for whatever reasons were not allowed to be used to solve this problem 

Now my friend tried to solve this problem in an interesting way. He Introduced RIPv2 as new IGP between R5-R3-R2 to ensure he doesn't have to change anything into existing IGP since there was a large IGP domain connected to this setup.

Using RIPv2 he injected default route into RIB of R2 and R3. He had to change distance of RIPv2 originated default route so that it can get priority over BGP injected default route. Than he tried Injecting Default Routes into OSPF domain towards R4 using "Default Information Originate " option. Since the control over path selection was required here, During default route injection he used Metric Type as 1 with Higher metric given while injection route at R3 as shown below:



Obviously the solution didn't work as expected and here is why:



As you can on R4 we still have two routes instead of one in Routing Table.

Can you figure out what's the problem here and how we can fix it in easiest way ?

Or You Have any other better solution to fix it while meeting the given restrictions ?

I'll post my solution to the problem after 2 weeks.

To be on same page here is the Addressing I Used in while labbing this up:


Here is relevant configuration:











Good Luck  !!! :)

HTH...
Deepak Arora
Evil CCIE


Update For Ref: See comments section for further information.






HTH...
Deepak Arora
Evil CCIE


7 comments:

Anonymous said...

Hey There. I found your blog using msn. This is an extremely well written article.
I will be sure to bookmark it and return to read more of
your useful info. Thanks for the post. I'll certainly
return.

Look at my web-site - Ricky Salvador

Unknown said...

Nice, have not seen FA been used this way before. Anyway looking at the design I guessed FA was the issue but was thinking old way of not having FA was causing the issue... was not thinking having an FA (of R3) was causing the issue. :-)
on R2 did "ip ospf prefix-suppression" to the link to R3 (23.0.0.0/24), which removed the FA making only R2 preferred.

Thanks
Kal

R4#sh ip route | s _0.0.0.0
Gateway of last resort is 150.0.0.2 to network 0.0.0.0
O*E1 0.0.0.0/0 [110/2] via 150.0.0.2, 00:00:11, Vlan1

1 150.0.0.2 68 msec 64 msec 76 msec
2 23.0.0.3 64 msec 56 msec 56 msec
3 35.0.0.5 96 msec 92 msec 72 msec

ESW1#sh ip ospf database external
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 2.2.2.2
Network Mask: /0
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 1

Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 3.3.3.3
Network Mask: /0
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 10000
Forward Address: 0.0.0.0
External Route Tag: 1

Failover was tested by disabling R5 link to R3 and R2 interface to 12.0.0.0/24 network, making R3 active with 10001 metric.

Unknown said...

Any other solution on this

A Network Artist said...

Thanks Kaivalya for your comments and participation.

I came up with same solution like you proposed.

Another possible solution could be to kill OSPF between R2-R3 but it really depends upon if customer agree to that.

I personally felt identifying OSPF FA issue here was quite challenging even for CCIE people and I must congratulate you for been able to find it successfully.

Suddarshan said...

Hi Deepak,

I understand the solution of
ip ospf prefix suppresion & the issue of Forwarding address via R2 is 23.0.0.3 & via R3 is 0.0.0.0 default route which is injected using OSPF.

But could you explain on how killing OSPF in between R2 - R3 would be helpful, since we have a default route via RIP & RIP is running in between R5, R3, R2.

suddarshan23 said...

Hi Deepak,

Nice Explanation, Just one clarification needed. By killing OSPF process in between R2 - R3, what will happen. Since we are still running RIP in between R5, R3,R2. Can the active path still be using RIP table.

Anonymous said...

if someone who watched Brian Machan CCIE RnS v5.0 Video series can identify this issue easily. He has explained everything in details.