Lets go down another layer in your proposed BGP solution. The core topology will be along the lines of 5-10 routers in a ring. Lets say 7 routers, R1, R2, R3, R4, R5, R6 and R7 are connected in a p2p ring topology. Assume that there's one or more direct connections between R1 and R4.
R4 has 3 other interfaces for networks A, B, and C. Each is a different service. Assume that R1 is connected to another cloud of routers and that traffic to networks A, B, and C will originate from this other cloud. The service routing requirements are as follows (from R1's perspective): * traffic to A should go follow the R1-R2-R3-R4 and/or the R1-R7-R6-R5-R4 path. * traffic to B and C should follow the R1-R4 path * when the link between R1 and R4 fails, B should be routed over the R1-R2-R3-R4 and/or R1-R7-R6-R5-R4 path. Traffic to C should stop. Provide some sample configs snipets for R1, R4 and an intermediate router which demonstrates how the proposed BGP solution would support the policy requirements. Thanks Zsombor Papp wrote: > > I am not sure what's the significance of the existing routing > setup. Is there a desire to preserve any part of it? > > Your new example is pretty much the same as I described the > problem, isn't it? So running BGP over I1 and I2 (just directly > to the neighbor routers) would still work. > > Or is the requirement to be able to make such a decision at > every single hop, not only at the end point? If so, using MPLS > and Traffic Engineering might really be a better option, > depending on how flexible your solution needs to be (ie. if > there are thousands of possible paths and you want to allow > only a few hundred, then that will be a nightmare even with TE). > > But let's consider a non-MPLS solution first. That would be > what you call the "BGP as IGP" approach (although I assume you > would still want to keep OSPF running to provide connectivity > between the routers). The most important issue here is how you > will make sure that the BGP sessions go up and down together > with the links they correspond to. With eBGP, this is easy as > you have direct control over the TTL of the BGP packets. With > iBGP, you would probably have to use the physical interfaces' > IP addresses for the BGP sessions (instead of the loopbacks, as > it probably is currently). Unless you can limit the TTL of the > iBGP packets (I don't remember if there is a way to do this in > IOS). > > Another issue with iBGP is that routes learned from an iBGP > peer are not advertised to another iBGP peer unless the local > router is a route-reflector, so you would probably end up > configuring every router except the end-points as a > route-reflector. On a second thought, this is probably not a > big issue, but I'll mention it anyway, maybe it rings an alarm > bell in someone else's mind. :) > > I am not sure if setting the next-hop at every router would be > necessary. The fact that in case of a link failure -- thanks to > the filters applied to the BGP sessions corresponding to the > still functional links -- there simply wouldn't be any routes > advertised, seems to be sufficient. If so, the advantage of > using iBGP would be that you could still rely on OSPF to select > the path for the services that are still functioning. Of > course, if a certain type of traffic is allowed on multiple > links, then you will have to make sure that the OSPF metric is > set so that the preferred link will be picked in case multiple > links are available. > > Yes, maintaining the filters won't be great fun, but I suspect > that it would be easier to comprehend than a per-serivce OSPF > topology. > > The "one AS per router" requirement for eBGP doesn't seem to be > very scary. An AS number is just a number, like the RID in > OSPF, which you have one per router, so unless you expect to > have 65000+ routers in this network, I don't see a problem with > that. Also, you can prepend AS numbers to emulate the IGP cost. > The bottle-neck of this approach might be the max allowed > length for AS_PATH attribute. I seem to remember that it's 128, > which is not a lot, but it's still better than old-style > metrics in ISIS... > > Speaking of scaling, do you think that one OSPF process per > service will scale? Since you will probably want to run all the > OSPF processes on almost every link and pretty much every > router, the load of running OSPF will be proportional to the > number of services. Will the routers be able to keep up? What > if they decide to add yet another service? Or three more? > > As for the ACLs, technically speaking, they do satisfify the > requirement that the end-points need to be notified. There will > be ICMP messages to this effect. You could extend the > application to look for those (or write a separate small > application). This might sound a bit crazy, but looking at the > other options, I am not sure this is the worst one... :) > > Thanks, > > Zsombor > > p b wrote: > > > > > > 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 > > > > > > > > > > > > > > > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73830&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
