When would you use multiple OSPF processes?

[PrimeYeti]

I have heard it said that having multiple OSPF processes is like having two completely separate IGPs on a single router. I know the process ID is local to the router and you can use it to split up an LSDB.

My confusion is that, OSPF areas already have their own LSDB, so only routers in that area will maintain an LSDB for said area. So what's the point of a process?

In what situation would you use multiple processes?

[David Ruess · Accepted solution]

Its the same concept as having a different EIGRP Autonomous systems running on a single router. Maybe you're doing VRFs and separating customer networks. Maybe you're doing MPLS L3VPNs and you are running OSPF from PE to CE routers. While yes the local router has its LSDB per area (if part of multiple Areas) but it will still know all the routes of a single process. Meaning that Area 0 and Area 2 on the same router will be able to communicate as they know about each others routes. With a separate process ID its just that. Separate and wont be able to communicate between each other. 

-David

[Martin L]

Some sort of migration comes to mind; Maybe your doing company-wide subnet migration/upgrade or redesign. Or doing Company merger (migration). In any case, I think running 2 processes is a temporary advantage.

To communicate between 2 different OSPF processes you must do redistribution between OSPF processes

Regards, ML
**Please Rate All Helpful Responses **

[MHM Cisco World]

Ospf prefer route from intra the  inter then external not prefer route depending on it metric.

So when we add additional process all route from ospf process will be external and ospf prefer route with lower metric.

[M02@rt37]

Hello @PrimeYeti,

You might have different OSPF instances for different purposes, such as separating OSPF configurations for customers or organizational units. This helps in isolating OSPF information and behavior. Assuming you have also VRF configured.

[Joseph W. Doherty]

"Assuming you have also VRF configured."

BTW, VRFs not actually required, in many cases, but can be beneficial if available.

[M02@rt37]

@Joseph W. Doherty 

It is beneficial if available.

[Joseph W. Doherty]

---

M02@rt37 wrote:

@Joseph W. Doherty 

It is beneficial if available.

---

Laugh, depends on what you're trying to achieve, which is why I wrote "can be beneficial".

VRFs, by default, isolate routes between them, including on the device hosting them.

Multiple OSPF processes, share their routes in a single route table, on the device hosting them (although they don't, by default, propagate them between the OSPF processes).

What you might have in mind, is each VRF having its own OSPF, but I think what OP has in mind is separate OSPF processes, on the same device, w/o VRFs.

Basically, its much like having, for example, an OSPF and EIGRP on the same device.  Same "rules" apply, although rather than having OSPF and EIGRP, you can have OSPF and OSPF.  (Of course, you don't run into different routing protocol attribute conversion issues.)

Somewhat similar to what @Richard Burts described, I've seen a large corporation use OSPF for a core AS IGP with regional ASs IGP also being OSPF.  This was later replaced with (the more common?) BGP for the core while still using OSPF for regions.

[M02@rt37]

@Joseph W. Doherty 

depends on what you're trying to achieve... you're totally right !

[Joseph W. Doherty]

"In what situation would you use multiple processes?"

Perhaps when you want to selectively control route redistribution between OSPF ASs.

[Richard Burts]

I worked with a client which was a business that provided services for multiple of its customers. They wanted their customers to have visibility of its corporate network but not to have any visibility of other customer networks. Part of the solution was a separate OSPF process for each customer.

[PrimeYeti]

Thanks for all the replies! I think the splitting a customer base scenario makes the most sense to me as you would want to split up customers and not have them communicate.

[Joseph W. Doherty]

---

@PrimeYeti wrote:

Thanks for all the replies! I think the splitting a customer base scenario makes the most sense to me as you would want to split up customers and not have them communicate.

---

It doesn't actually preclude communication, although @David Ruess mentions that too ("With a separate process ID its just that. Separate and wont be able to communicate between each other.")

Again, by default, the separate OSPF processes don't redistribute each other's routes, but (w/o VRF), the device with the multiple OSPF processes loads all routes into its route table.  So if a packet from one topology makes it to the router with both topologies, that router will forward the packet into the other OSPF topology (of course assuming the other topology has that route).

You might be wondering, though, why/how a packet would be sent to the router knowing the two topologies if neither topology is advertised to the other?  Well, one way would be for the router hosting both OSPF topologies to advertise, to each, i.e. that router is the egress router for unknown destination packets (i.e. advertise the

default route

).

(BTW, a router hosting two non zero OSFP areas, will also route between them, but also not share each topology's routes with the other topology.  Big difference, you cannot configuration redistribution between two non zero areas, etc.)

I touched on this in one of my prior replies, but what this allows is using the same routing protocol, OSPF, to effectively provide separate ASs.  At the interconnection between OSPF ASs, you have control over what you what each AS to "know" regarding routes.  You can, though, also actually control communications, using ACLs.

Also again, envision a large corporation with regional OSPFs, tied together via BGP.  Just replace BGP with OSPF, and, logically, you've still what you had for management purposes (although impacted, both plus and minus, with feature differences between BGP and OSPF for the central routing protocol).