Dynamic Routing on MPLS network with IPSEC VPN as backup route

[BDS_Vince]

We are new to the Palo Alto community and are looking for some advice as the best way to accomplish our networking end-goal.

We have several remote offices that are currently connected to corporate using an IPSEC VPN over the internet.  Each site has a PAN device.  We are looking to add an MPLS network to act as the primary route between each of our sites.  This change is being driven by the implementation of a VoIP based phone system and we don't think a hub and spoke design is the best approach/

We have MPLS connections at a couple of sites now.  The current implementation has an IPSEC tunnel accross the MPLS network that relies on weighting in the virtial switch to deteremine which route to take. 

I'd like to remove the IPSEC tunnels over the MPLS network to allow for direct site to site traffic.  To do this I have to advertise the local networks behind the firewall.  The current IPSEC setup uses OSPF.  The MPLS routers use BGP.  I *think* I can use OSPF and have the PANs act as neighbors which should simplify advertisement.  What I'm unsure about is how to create the dynamic routes over the MPLS network.

Do I create a new "area" for the MPLS network or do I add it to the existing area? 

If I use the same area then I have to give the MPLS a "Higher" priority.  The documentation I've found says thats from 1-255 but it doesn't say if 1 is the highest priority and 255 is lowest (or vice-versa).

I've searched this site and haven't found an answer.  Is there a HowTo or technical article I missed?

Any advice would be welcome.

TIA!  

[pulukas]

In general, we use OSPF areas in order to keep the database size reasonable in large networks.  so in your case it sounds like you won't have a problem just keeping everything in area 0.

You can use the link cost attribute in OSPF to steer the traffic to prefer the MPLS path over the IPSEC internet path.

[BDS_Vince]

Thanks for the reply!

My testing shows that this approach works well.  Now for the next hurdle...

The consultant that ordered and configured the MPLS network put each node on a different network.

Example:

GW 10.2.1.1/16, Firewall 10.2.1.10

GW 10.3.1.1/16, Firewall 10.3.1.10

As a result the Firewalls do not locate any OSPF neighbors.

Is there a way to manually specify the OSPF neigbors since they are essentially on different networks?

I can have the MPLS network changed but that will break the current IPSec tunnels....

[pulukas]

Unfortunately, OSPF does require the devices have interfaces in the same network.  You will need to use BGP which does support multi-hop required in this scenario.

[OtakarKlier]

Hello,

I have worked with MPLS in the past and our solution to advertise routes was to allow our systems to advertise/share routes via the providers equipment. The provider shared OSPF with us and that is how we injected/advertised our subnets to the other sites.

Just a thought.

[abjain]

I think you are past the query obout priority, but I dont see how priority will affect anything here. Priority on OSPF interfaces is to influence the DR/ BDR election. In this case I think metric should be used to influence which path should be used.

I am assuming you have a topology like this.

PAN ------ PE ---- MPLS (BGP) ---- PE------ Remote Site

  \ -------------- OSPF over IPSEC --------------/

In this case you can ask PE to run BGP with PAN firewalls and then you can use administrative distance for BGP learned routes to be preferred over OSPF learned routes over the tunnel. Also from the PAN firewalls you will have to redistribute the local routes to BGP peers.

Or if you are interested in running OSPF on PAN, then you can do the same, provided the PE router and the PAN share a common network. In this case, you cannot let the OSPF over IPSEC and OSPF to PE run in same virtual router as it will cause the OSPF to advertise your link to PE over IPSEC, which will cause tunnel to flap.

You will need to have to use another virtual router for the OSPF to PE. You can still use the same area as the one for IPSEC ospf.

[BDS_Vince]

We had a meeting with our MPLS provider yesterday and determined the same thing you posted about.  They are willing to host startic routes but will not let us send updates to their routers.

I think we're to the point where we are going to rely on the netmask of the Local IP on the router to manage routing and not use OSPF at all.

Example:

Site 1

FW IP: 10.1.1.10/16

Router LAN IP 10.1.1.1/16

Subnets: 10.1.10.0/24, 10.1.80.0/24

MPLS Cloud

Site 2

FW IP: 10.2.1.10/16

Router LAN IP 10.2.1.1/16

Subnets: 10.2.10.0/24, 10.2.80.0/24

We would have to have the provider hard code routes for some legacy networks

on IP address groups 192.168.x.x and 172.16.x.x connect to the corporate firewall.

We will fail-over to an ipsec tunnel over the untrusted internet connection iof the mpls

network is down.  We recongnize that this is a fail from a mesh to a hub and spoke.

Thanks for your response!

[J.Carrizosa]

abjain, your diagram is very similar to what I'm trying to do. We plan to run bgp with our mpls provider and exchange routes that way, I was curious if we can/should use bgp as well inside our ipsec tunnels back to our palo alto's at our two main hub sites. Looking at the pluses or minuses of this option; for example, we wouldn't have to redistribute routes between ospf and bgp.

We also will have a third available path at each site (an sdwan solution that we are testing), and we're doing bgp with the sdwan appliance. So perhaps there's an advantage with staying in bgp for all 3 different "zones". The goal is to keep mpls primary and fail to vpn (or keep sd-wan as primary, fail to mpls 2nd and ipsec 3rd for sites that have the sdwan box).

It may also be advantageous to fine-tune traffic based on specific routes across all these different path options, and bgp may be more flexible using route filtering and/or AS-prepending per route. Just don't know if there are any downsides to using bgp. And if there are gotchas with Palo Alto's bgp implementation?

Any thoughts on these options are appreciated, thanks.