cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
515
Views
0
Helpful
6
Replies

OSPF Path Selection

hypnotoad
Level 3
Level 3

Hey All,

I'm labbing up some BGP-MPLS and OSPF routing solutions. I'm doing mutual redistribution of BGP and OSPF at my WAN edge with route tagging for loop prevention. I'm setting local pref to 50 and weight to 0 when distriibuting OSPF to BGP. That all seems to be working fine.

I have DMVPN with OSPF as a backup path.

Below are two route statments from my core router where the two paths meet. The router always prefers the DMVPN path over the MPLS path. Both routers are Ext2 with AD 110. The Metric for the MPLS path is 1 and the DMVPN is 20. What am I missing?

Routing entry for 10.85.100.0/24

  Known via "ospf 100", distance 110, metric 1

  Tag 777, type extern 2, forward metric 10

  Last update from 192.168.1.2 on FastEthernet0/0, 00:00:57 ago

  Routing Descriptor Blocks:

  * 192.168.1.2, from 192.168.255.2, 00:00:57 ago, via FastEthernet0/0

      Route metric is 1, traffic share count is 1

      Route tag 777

Routing entry for 10.85.100.0/24

  Known via "ospf 100", distance 110, metric 20, type extern 2, forward metric 120

  Last update from 192.168.1.6 on FastEthernet0/1, 00:00:04 ago

  Routing Descriptor Blocks:

  * 192.168.1.6, from 192.168.255.6, 00:00:04 ago, via FastEthernet0/1

      Route metric is 20, traffic share count is 1

--Patrick

6 Replies 6

Jon Marshall
Hall of Fame
Hall of Fame

Patrick

Are you saying both these routes are in the routing table at the same time ? They shouldn't be. So a "sh ip route | include 10.185.100" shows both routes ?

Jon

No. Only one route is there at a time. I made a bit of progress on this. OSPF routes are coming through the DMVPN link and being injected into BGP from both sides of the BGP-MPLS network. I changed the DMVPN top opetrate within it's own OSPF process id and am doing OSPF to OSPF redistribution with tags just like the BGP side. This seems to work well. I think there must be a more elegant method.

Now i'm getting confused although it may be because i haven't used DMVPN before.

I assumed DMVPN with OSPF meant that the routes you would see coming through would be internal to the OSPF domain. But your original post shows both OSPF routes to be type 2 so i assumed you were already doing OSPF to OSPF redistribution.

Jon

They were showing up as external because I was injecting routes at the source via the "redistribution connected subnets" command. This was needed or the routes would show up via DMVPN as Intra-Area or Inter-Area routes while the BGP-MPLS path would always be external. That is not nessesary now that OSPF to OSPF is working on the DMVPN side of the network.

Thanks for getting back. makes more sense now.

Is there a more elegant solution ?

Not necessarily. When doing mutual redistribution you should use route tags and with a backup link it can become complex. If you can summarise down the backup link both ways and send more specific via BGP then that can help but you still need a way, with OSPF to make the backup link advertised routes external.

I'm still not sure of your topology ie. i was assuming a L3 switch/core router sitting behind your WAN routers so what i'm suggesting next may well not work.

One thing that occured with your original setup was that OSPF type 1 externals are preferred over type 2 so when you redistribute BGP into OSPF you could make those type 1 and these would automatically be preferred over the DMVPN learnt routes which are type 2 within the rest of your network.  Because you are redistributing OSPF back into BGP when you do the redistribution you could match on type 2 with a route-map and stop those being redistributed. The only type 2s you should see would be the ones from the DMVPN link.

But then again, even if that worked is it better than your solution. Not really because you are still controlling which routes are redistributed just not using tags and route tagging is the suggested approach for performing mutual redistribution.

Perhaps the answer is not to use mutual redistribution but that can rely on summarisation ie. if you could summarise each site to the other do that via the backup link. And then advertise the more specific subnets via BGP network statements. Then you don't need any redistribution in OSPF because even though the routes would not be seen as external there would always be a more specific match from the BGP to OSPF routes. Ideally you would want to be able to summarise the entire site at each end with one entry and then possibly use more specific summary routes for the subnets via BGP so that cuts down on the network statement. They only have to be more specific than the summary received via the DMVPN link.

Still not sure that's any better to be honest. And if you can't summarise it's not a solution at all. 

So it is complicated. In my last job we had a similiar sort of problem with BGP MPLS and EIGRP. We had two main sites that connected to MPLS and these sites had a backup link between the core L3 switches down which EIGRP routes went. If the backup link was meant to be used for those sites to talk to each other it would have been easy but instead traffic had to use the MPLS connection unless it failed and then it used the backup. We ended up having to summarise on the backup links, use MED to influence the path into each site so they could also advertise out each others subnets for failover and if i remember correctly weight as well. And we were only doing redistribution from BGP to EIGRP. I remember looking at the final config in the lab and thinking there must be a better way.

Anyway, apologies if i have misunderstood or bored you stupid.

Jon

I'm still exploring other options. Thanks for the responses so far. I'm exploring the use of ospf sham links as a possible solution.

--Patrick

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco