Here's some more detail. Yes, assume the destination address (networks) represent the corresponding service.
This is an existing production network where OSPF and iBGP are already in use for the existing (single) service. OSPF carries p2p and loopbacks; iBGP carries customer end-point networks. We want to overlay two other services. The paths the packets take to their destination, even if hosted on the same router, will be different. Further, when there's a failure in the network, the manner in which traffic gets re-routed will be specific to each service. An example might help. Consider some router R1 in this network. It has several connections to other routers in the network. It also has three interfaces each with a network assigned to it. Lets call these networks A, B and C and each is for a different service. Under normal conditions, traffic to A comes in via interface I1 and traffic to B and C comes in via interface I2. Now assume I2 fails. Traffic for A and B should come in over I1 and traffic to C stops being delivered. ACLs won't work in this situation for a number of reasons. Besides the configuration and operational issues, another requirement is that the end-points generating traffic to destinations in C will want to know when C is unavailable via I2. They'll want to know this so they can stop generating traffic or leverage some higher level (service specific) mechanism to address the failure. Running BGP as the IGP might work, but I'm not sure. I think it might need to operate in iBGP mode and I think it would require lots of policy filters on all outgoing advertisements and would probably require setting the next hop at each router. These are both typically not done when operating in iBGP mode. Further, I think one would lose the concept of IGP cost; the iBGP mechanism might allow one to construct a path between two end-points which satisfies the service policy, but if multiple paths exist, the concept of link cost would not be available. I guess running eBGP as the IGP could also work, but now we're talking configuring a unique AS for each router (which doesn't scale). One could see the path selected through the network via the AS_PATH attribute, but there still would be no concept of IGP cost. I've not come up with a way to solve this without moving to a model where theres an IGP and thus SPT for each service, which implies multiple OSPF processes. But I'm interested in other thoughts or options on this... Zsombor Papp wrote: > > 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 **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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73820&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
