OSPF, VPN, routing and distribution

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

OSPF, VPN, routing and distribution

L1 Bithead

I'm trying to solve a routing conundrum to improve a remote site and provide redundancy, and hoping others may have some solutions. The short version is that we have the remote site with basic commodity internet using VPN to connect back to two datacenters. The datacenters in turn have direct links to each other, and all are running OSPF.

 

The issue - datacenter 1 and datacenter 2 use area 0 for all inter-site connections. When adding the remote site to this with the VPN connections, everything appears fine, but if there is a disruption to the link between datacenters, the remote is advertising the routes between them. In testing, even though everything was theoretically clear we experienced issues as the remote advertised the paths to each other, causing issues with communications between the datacenters.

 

I tested with dedicating a stub area for the VPN tunnels to the remote, however, it appears that we lose inter-area OSPF when this is done and you can't define an OSPF redistribution rule for OSPF, so everything known behind the datacenter palos is lost. 

 

Below is a simplified diagram of the network with placeholder IPs:

 

PAN OSPF.PNG

6 REPLIES 6

Cyber Elite
Cyber Elite

Hello,

The way we solved our issue with this is to weight the OSPF links to the DR data center to force the connection. We made the remote office also area 0 to keep things simple and not have issues with LSA's. so our primary link is the default and we made the cost of the DR link much higher, like 10000 or if it was the 3rd backup link 20000.

image.png

 

Hope that helps!

 

That does help a bit to make sure that it isn't a preferred route under normal conditions.  The problem I'm looking at is that in the case of loss of the MPLS connection between DC1 and DC2, the DCs see a route through the remote site to each other. Suffice to say, the remote site doesn't have the bandwidth to handle DC to DC traffic. Even setting the metric to max (65535) and the priority to max (255), if I cut that link in the lab the two DCs route through the VPN. The preference would be that the DCs not be able to see each other through the remote.

We had the same concerns. How about a VPN tunnel between the DC's as a backup to the MPLS? That was our solution. That way it uses the internet circuit and not the remote offices.

L5 Sessionator

Are the data center OSPF devices PAs also?

When you tried creating the branch as a stub, what did you configure on all devices?

The data center devices are also Palos, and there are other areas, as well as some BGP going on behind them (the diagram is drastically simplified). When I tested with the lab devices, I created a stub zone between the three, and found that it the DCs could still see each other through the stub and they stopped inter-zone advertising so the remote could only see what was in the area. At this point I'm looking into non-routing solutions (ie. VPN tunnel failover options, or feasibility of a single link for the remote) as I'm realizing that there may not be the tools available to manage this in Palo routing.

Hello,

What about a VPN over the internet between the two PAN's. That way its always data center to data center traffic, MPLs is preferred but VPN is backup.

 

Thoughts?

  • 2573 Views
  • 6 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!