Routing via PBF vs OSPF

[locampo]

I’m working on an implementation for about 15 branch offices where my organization is replacing an inconsistently-configured mix of SonicWALL and PA hardware with mostly PA-220’s. Each office has a Metro-Ethernet connection (100 Mbps at branches and 1 Gbps at HQ) and will also have an IPSec VPN tunnel back over their local internet connection back to the main office. Was handed a design by a previous engineer that intended to use PBF to provide failover between these two paths back to HQ. Made total sense up until now.

Until the other night when we found some of these offices were already using a VoIP system which the others will eventually be using as well. In order for their phones to support dialing internal extensions between branches, each site will need to be reachable from each other site. We could keep the current design, so long as we routed everything through HQ, but I’m concerned that additional hop could impact performance, particularly with the phones and particularly in a failover scenario where the tunnel over the internet is being used.

So, what was designed as a hub and spoke is now looking like it will need to be a full mesh. With the number of routes per site and the need to have PBF and monitors set up for each, I’m starting to feel like OSPF might be a better choice for routing. I was wondering what thoughts others had on using PBF vs OSPF in this scenario. I’ve never peronsally used OSPF, but thie project looks like it’s exceeding the practical limit for using static routing or PBF, so any guidance or advise would be appreciated. My only hessitation with OSPF is not being familiar with its quirks in real world situations.

[pulukas]

I would tend to use dynamic protocols first in any routing situation before resorting to PBF as a general rule.  The use of PBF should be restricted to situations where normal destination routing selection is simply not sufficient for the task.

In your case it would appear that a simple OSPF setup with link cost assignments would do the job.  You would need to carefully layout the link costs so that hopping from one remote site through a second remote site to reach the hub site would not be selected as a general rule.

If you did need more fine control of the routing policy, then BGP would be the next step before resorting to PBF.  OSPF gives little control over route distribution.  But BGP would give you that control if you needed to be sure that specific routes were restricted to certain locations or excluded all together.

[locampo]

Thanks for the response, @pulukas.

The way I've done this in the past has been strictly using PBF, but I come from an SMB background. In those situations, I was using PBF to provide failover across 2-3 connections to a central office in a hub-and-spoke model. In that kind of a scenario, PBF makes sense (if you're not already comfortable and confident with using a dynamic protocol). 

With this project requiring a full mesh topology, the sheer number of paths at each site and total number of routes and monitors seems like a practical limit for PBF. But I was eager to get feedback from others like you who've actually used OSP outside of a lab environment. As far as BGP, wouldn't that be overkill here? The only place I've encountered BGP in use is at a previous MSP I worked for where they needed BGP at their edge to provide seemless redundancy across their two ISP connections for the level of uptime they needed. From what I do know of BGP, it seems like the most complex way to go from routing in the organization.

What about other dynamic protocol options? EIGRP, for example? OSPF was my initial thought just because it seemed simpler, but I'm not very familiar with the realworld pros and cons of these various options. Could that be somewhere inbetween OSPF and BGP in terms of complexity (and required expertise) vs control and reliability?

EDIT: Sorry. I see now that PAN doesn't support EIGRP... so, I suppose my options are RIP (which is just a bad idea, right?), OSPF, or BGP.

As far as link costs, that is exactly my concern with using any protocol. Not having done this before, I'm not quite sure exactly how I would want to weigh my paths to prevent assymetric routing and/or other odd pathing issues. I don't want to save configuration time just to have to spend more time troubleshooting issues with the protocol, you know?

Thanks again for taking the time to help with this.

[pulukas]

Right, EIGRP is a Cisco proprietary protocol that they partially released in an RFC to pretend it is a general standard.  So you won't find it on anyone elses gear.

I've used OSPF on similar VPN mesh networks, the largest having about 90 nodes with 5 regional meshes and a central data center to all sites.  This can be very simple to configure and with careful path counting you can choose link costs that prevent major asymmetry.  And if you keep all the tunnel interfaces in the same zone on the device, even if the traffic is asymmetrical it can still match the session on arrival.

The key is to layout the map then mentally down links and count each possible alternate path for the affected traffic adding up the costs.  then make adjustments as you need to that prevent strange routing patterns.

Using eBGP on large site connections is extremely flexible.  You then have a private AS for each site as a unique source for routes.  Your policies can finely control the routing preferences per peer or even per prefix.  This is more complex to setup but can be more predictable in how the routes move around the system.  You can prevent certain paths from even becoming available via policy thus avoiding the odd long loops.