Since you say you want to run one OSPF process for each traffic type, I assume the type of the traffic is defined by destination IP address. If this is not correct, then I would be curious to know what a "traffic type" is and how you will associate a traffic type with an OSPF process.
If however my assumption is correct, then I can see several ways to solve the problem you cited as an example, with BGP or with a single OSPF process. Let me restate the problem for N=1: suppose there are 3 routers, R1, R2, R3, connected in a triangle. Both traffic A and B usually go directly from R1 to R2, but when that link fails, traffic A should go from R1 to R3 to R2, and traffic B should be dropped at R1. Solution with BGP: run BGP between R1-R2 and R1-R3, make the routes coming from R2 preferred, and filter out the routes corresponding to traffic B from the advertisements R3 sends to R1. Solution with single OSPF process: configure an access list on the link between R1-R3 that drops traffic B. :) Of course I might be missing something, so feel free to point out why these wouldn't work in your case. Thanks, Zsombor p b wrote: > > > Using multiple processes might provide a way to implement > policy at the link level. Typically, when one thinks of > policy, > one thinks of BGP. But what if your policy requires the ability > to control what traffic can or can't go over a particular > link? For example, consider two routers, that are > interconnected > by a direct link and a N-hop L3 path. Suppose traffic types > A and B should typically go over the direct link but, if the > direct link fails, traffic type A should be routed over the > N-hop L3 path and traffic type B should not be forwarded. > > I don't believe there's a way to get this level of policy from > a single OSPF process or a single OSPF process coupled with BGP. > > However, if you run multiple OSPF processes, say one for each > interesting traffic type, and if you use BGP to set a network's > next-hop to match the right OSPF RID, and for each link define > a sub-interface (or not) for each OSPF process, then I think the > above routing requirements might be supported. > > MPLS might work here, but I'm not sure. > > > > > > Suppose you have certain types > of traffic that > > Zsombor Papp wrote: > > > > What are you trying to achieve with these ~3 OSPF routing > > processes? > > > > Thanks, > > > > Zsombor > > > > p b wrote: > > > > > > > > > I'm considering a routing architecture where devices in the > > > network would run ~3 OSPF routing processes. > > > > > > I think each routing process will be handling the routing > > > of non-overlapping address blocks and thus the routes they > > > give to the forwarding table should be disjoint. > > > > > > However, I'd like to understand what happens if two > processes > > > each were to provide the same prefix to the forwarding > table. > > > Specifically, what are the rules to determine which prefix > > > is put into the routing table? > > > > > > Also be interested in any learnings folks might have had > when > > > they've run multiple OSPF processes. > > > > > > Thanks > > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73794&t=73727 -------------------------------------------------- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
