multiple ospf processes & route insertion [7:73727]
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=73727&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
Re: multiple ospf processes & route insertion [7:73727]
Is this correct? Off the cuff, I would think that the route with the lowest cost would be inserted into the table, and if they both have the same cost, wouldn't both routes be inserted and then load balancing occur? Again this is not lab tested, but just my initial thoughts... Mark - Original Message - From: "Zsombor Papp" To: Sent: Friday, August 08, 2003 12:44 PM Subject: RE: multiple ospf processes & route insertion [7:73727] > The process with the lower administrative distance will install the prefix > into the routing table. If the administrative distances are the same (and > they are by default), then the process that "comes first" will install the > route. In other words, it is not deterministic unless you change the default > admin distance. > > 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=73751&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
RE: multiple ospf processes & route insertion [7:73727]
well, in my thoughts, there is no loading balance in ospf. it will choose only one route and put it into its ospf routing table. also i got a case: when there is a route from EBGP peer which is 192.168.0.0/19 and also a route comes from static input which is 192.168.0.0/18, which one do you think the router will pick ?? the answer is : the route from EBGP! Jason G.F CCNP Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73764&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
RE: multiple ospf processes & route insertion [7:73727]
Wow, um, err, no offense, but you're a CCNP? And confused about the concept of a route table? There can't be the same route for BGP and a static in the active routing table concurrently. That is unless you do something weird like set the administrative distance of the static route equal to that of the BGP route, but I'm not even sure about that. From your past posts, you are probably seeing two different routes, with the same prefix but different masks, in the routing table. 192.168.0.0/18 and 192.168.0.0/19 are not the same route. It might make it easier to follow if you quoted at least the post you are replying to... Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Jason J [mailto:[EMAIL PROTECTED] Sent: Saturday, August 09, 2003 3:32 PM To: [EMAIL PROTECTED] Subject: RE: multiple ospf processes & route insertion [7:73727] sorry , i think what i've said is totally wrong!.god damn. i'am a little dizzy. confused about the concept of route table. i'am just doing experiments on routers. dizzy. since the same routes from different protocols can not be present on the route table , but why do i saw there are the same route from BGP and Static?? :( Jason J CCNP P.R.C **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=73791&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
RE: multiple ospf processes & route insertion [7:73727]
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=73789&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
RE: multiple ospf processes & route insertion [7:73727]
Dear Fred in fact, 192.168.0.0/18 does include 192.168.0.0/19 and 192.168.32.0/19.wherenever router choose route, it will always pick the most concrete one so even 192.168.0.0/18 is static, it will choose the one from EBGP, 192.168.0.0/19. when the route from EBG is 192.168.0.0/18 and there is static route 192.168.0.0/18, sure the router will choose the static one. Jasong.J CCNP P.R.C Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73776&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
RE: multiple ospf processes & route insertion [7:73727]
er.Sorry about that! I Think i make a mistake, I did no see two same routes from two different routing protocols. in fact, one is "61.168.0.0",another is" 161.168.0.0" . really sorry for put so much trouble on you. everything comes from my experiments's wrong result. the wrong result comes to the wrong conclusion. so ,really thanks a lot , Zomber and Fred. for pointing out my mistake, so i can get a chance to learn more. Jason.J CCNP P.R.C Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73798&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
RE: multiple ospf processes & route insertion [7:73727]
I assume you meant R4 not R1 here: > 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. And you didn't say what should happen if both the R1-R2-R3-R4 and R1-R7-R6-R5-R4 path are unavailable, so I will assume only traffic B and C are supposed to go through via the R1-R4 link. (Though it wouldn't make a big difference if traffic A needed to go through there, too.) I am also a bit uncertain why the routing requirements are stated "from R1's perspective", if they refer to the traffic that goes *to* R1. I'll assume this is just an oversight and you are not interested in how traffic *from* R1 will be routed. Having said that, my suggestion would be to run eBGP between - R4-R1 and filter out network A and increase the weight of network B, - R4-R3 and filter out network C, and - R4-R5 and filter out network C. R4 should run OSPF only on the interface towards the cloud, ie. R4 would talk only BGP towards R1, R3 and R5, and you would redistribute BGP into OSPF on R4. R3 and R5 could learn A, B and C via OSPF, I don't see why they would have to run BGP towards R1/R2/R6 (but they can if you want that). I think the above description pretty much nails down the configuration. If you really want specific configs, then tell me which part you are not clear about. Thanks, Zsombor p b wrote: > > > 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 > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73849&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
RE: multiple ospf processes & route insertion [7:73727]
er.Sorry about that! I Think i make a mistake, I did no see two same routes from two different routing protocols. in fact, one is "61.168.0.0",another is" 161.168.0.0" . really sorry for put so much trouble on you. everything comes from my experiments's wrong result. the wrong result comes to the wrong conclusion. so ,really thanks a lot , Zomber and Fred. for pointing out my mistake, so i can get a chance to learn more. Jason.J CCNP P.R.C **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=73814&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
RE: multiple ospf processes & route insertion [7:73727]
O.K., no problem, everyone makes mistakes, and that was a pretty easy one to make. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Jason J [mailto:[EMAIL PROTECTED] Sent: Sunday, August 10, 2003 3:04 AM To: [EMAIL PROTECTED] Subject: RE: multiple ospf processes & route insertion [7:73727] er.Sorry about that! I Think i make a mistake, I did no see two same routes from two different routing protocols. in fact, one is "61.168.0.0",another is" 161.168.0.0" . really sorry for put so much trouble on you. everything comes from my experiments's wrong result. the wrong result comes to the wrong conclusion. so ,really thanks a lot , Zomber and Fred. for pointing out my mistake, so i can get a chance to learn more. Jason.J CCNP P.R.C **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 **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=73838&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
RE: multiple ospf processes & route insertion [7:73727]
er.Sorry about that! I Think i make a mistake, I did no see two same routes from two different routing protocols. in fact, one is "61.168.0.0",another is" 161.168.0.0" . really sorry for put so much trouble on you. everything comes from my experiments's wrong result. the wrong result comes to the wrong conclusion. so ,really thanks a lot , Zomber and Fred. for pointing out my mistake, so i can get a chance to learn more. Jason.J CCNP P.R.C **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 **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=73831&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
RE: multiple ospf processes & route insertion [7:73727]
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 tr
RE: multiple ospf processes & route insertion [7:73727]
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 tr
RE: multiple ospf processes & route insertion [7:73727]
Yeh, you are righ, Zsombor. in fact, i just want to say that .for 192.168.0.0/24---192.168.31.0/24 ,the router will use 192.168.0.0/19 from EBGP,not the static one "192.168.0.0/18". also if you tyep" show ip route 192.168.0.0 " , the router show u the 192.168.0.0/19. By the way ,i just understand what p b was interested in. i'm also interest in it too! If two ospf processes learn the same network route,what will happen then ?? :) Jason J CCNP P.R.C Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73783&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
RE: multiple ospf processes & route insertion [7:73727]
Dear Fred "Wow, um, err, no offense, but you're a CCNP? And confused about the concept of a route table? " everyone could get confused about anything :). especially in some 2 or 3 am morning. first sorry about that. "There can't be the same route for BGP and a static in the active routing table concurrently. That is unless you do something weird like set the administrative distance of the static route equal to that of the BGP route, but I'm not even sure about that. " yes, i do saw two same routes ,one from EBGP ,one from static. both them are 192.168.0.0/17. one AD is 20 another is 110. best regards. Jason J. CCNP P.R.C **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=73843&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
RE: multiple ospf processes & route insertion [7:73727]
er.Sorry about that! I Think i make a mistake, I did no see two same routes from two different routing protocols. in fact, one is "61.168.0.0",another is" 161.168.0.0" . really sorry for put so much trouble on you. everything comes from my experiments's wrong result. the wrong result comes to the wrong conclusion. so ,really thanks a lot , Zomber and Fred. for pointing out my mistake, so i can get a chance to learn more. Jason.J CCNP P.R.C **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 **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=73818&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
RE: multiple ospf processes & route insertion [7:73727]
Dear Zsombor: "You can't put the same interface into multiple OSPF processes but that doesn't mean that the two processes can't learn about the same network." if you can't learn put one interface into multiple OSPF processes, then except you redistribute the direct donnected and static, how could they learn the same address ,learn from each other? i think the same condition exist on other routes ,how could a network link's status be share with other ospf process without put the sme interface into multiple OSPF processes? best regards Jason J CCNP P.R.C Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73797&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
RE: multiple ospf processes & route insertion [7:73727]
The process with the lower administrative distance will install the prefix into the routing table. If the administrative distances are the same (and they are by default), then the process that "comes first" will install the route. In other words, it is not deterministic unless you change the default admin distance. 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=73741&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
RE: multiple ospf processes & route insertion [7:73727]
sorry , i think what i've said is totally wrong!.god damn. i'am a little dizzy. confused about the concept of route table. i'am just doing experiments on routers. dizzy. since the same routes from different protocols can not be present on the route table , but why do i saw there are the same route from BGP and Static?? :( Jason J CCNP P.R.C Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73786&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
RE: multiple ospf processes & route insertion [7:73727]
Yup, it is a traffic engineering (service specific routing) problem. MPLS TE might be one way to solve this.I've honestly not looked at what it would take to get MPLS to run in this environment.However, enabling MPLS on the network would be a major undertaking so I've been looking at what other options might be possible. Zsomber has suggested using eBGP in order to enforce the policy (thanks). As the proposed network evolves, and direct links are built to many of the other ring routers, the eBGP solution would require running eBGP each link. This doesn't seem like the right path to take. An approach with using 3 OSPF processes and corresponding sub-interfaces leverages features we enable today. Granted we don't run 3 OSPF processes, but we do run one, so it may not be as big a deployment and operation stretch to go this route. As I surfed the net looking for other options, I ran across the concept of logical routers available in JUNOS (6.0?). I just glanced at the web site, and the multiple OSPF process concept seems similar to Juniper's logical router concept. I've attached the Juniper link for those interested. Apologies in advance for doing this on the cisco list... http://www.juniper.net/techpubs/software/junos/junos60/feature-guide-60/html/fg-logical-routers.html Howard C. Berkowitz wrote: > > I freely admit that I've lost the sense of the problem that > actually > needs to be solved, with all the discussion of the various > tables. > Before my brain started to reboot, however, it sounded like it > was a > traffic engineering problem. Has anyone looked at the OSPF > Traffic > Engineering extensions here? > > Also, I got an impression that people didn't want to use MPLS > for a > TE problem. Why? That's essentially what it's for. > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73943&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
RE: multiple ospf processes & route insertion [7:73727]
So you want to solve a traffic engineering problem with MPLS/TE, huh? How boring... :) Howard C. Berkowitz wrote: > > I freely admit that I've lost the sense of the problem that > actually > needs to be solved, with all the discussion of the various > tables. > Before my brain started to reboot, however, it sounded like it > was a > traffic engineering problem. Has anyone looked at the OSPF > Traffic > Engineering extensions here? > > Also, I got an impression that people didn't want to use MPLS > for a > TE problem. Why? That's essentially what it's for. > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73938&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
RE: multiple ospf processes & route insertion [7:73727]
Jason J wrote: > > well, in my thoughts, there is no loading balance in ospf. There is, just not between processes. > it > will choose only one route and put it into its ospf routing > table. > also i got a case: when there is a route from EBGP peer which > is 192.168.0.0/19 and also a route comes from static input > which is 192.168.0.0/18, which one do you think > the router will pick ?? > the answer is : the route from EBGP! The answer is "both routes will be in the routing table and it depends on the destination address of the packet which one will be used for forwarding." Obviously, you can't forward a packet to 192.168.32.x based on a route to 192.168.0.0/19. Thanks, Zsombor > > Jason G.F CCNP > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73781&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
RE: multiple ospf processes & route insertion [7:73727]
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, anot
RE: multiple ospf processes & route insertion [7:73727]
"OSPF process" is a per-router thing. You can have two processes on one router talking to a single process on another router (over two separate links), for example. Thanks, Zsombor Jason J wrote: > > Dear Zsombor: > "You can't put the same interface into multiple OSPF processes > but that doesn't mean that the two processes can't learn about > the same network." > if you can't learn put one interface into multiple OSPF > processes, > then except you redistribute the direct donnected and static, > how > could they learn the same address ,learn from each other? > i think the same condition exist on other routes ,how could a > network link's status be share with other ospf process without > put > the sme interface into multiple OSPF processes? > > best regards > > Jason J CCNP P.R.C > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73817&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
RE: multiple ospf processes & route insertion [7:73727]
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 tr
RE: multiple ospf processes & route insertion [7:73727]
Am I missing something here? 192.168.0.0/18 and 192.168.0.19/19 are two different routes. It should put both of them in the routing table, not choose between them based on administrative distance. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Jason J [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 8:43 PM To: [EMAIL PROTECTED] Subject: RE: multiple ospf processes & route insertion [7:73727] well, in my thoughts, there is no loading balance in ospf. it will choose only one route and put it into its ospf routing table. also i got a case: when there is a route from EBGP peer which is 192.168.0.0/19 and also a route comes from static input which is 192.168.0.0/18, which one do you think the router will pick ?? the answer is : the route from EBGP! Jason G.F CCNP **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=73772&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
RE: multiple ospf processes & route insertion [7:73727]
Dear Fred "Wow, um, err, no offense, but you're a CCNP? And confused about the concept of a route table? " everyone could get confused about anything :). especially in some 2 or 3 am morning. first sorry about that. "There can't be the same route for BGP and a static in the active routing table concurrently. That is unless you do something weird like set the administrative distance of the static route equal to that of the BGP route, but I'm not even sure about that. " yes, i do saw two same routes ,one from EBGP ,one from static. both them are 192.168.0.0/17. one AD is 20 another is 110. best regards. Jason J. CCNP P.R.C Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73796&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
RE: multiple ospf processes & route insertion [7:73727]
Fred is right all routes from different routing protocals will be put into route table ,but!! even if they are the same ! and what i mean in the last article is the "ospf routing table", not route table.even there can be more same network link in its ospf database. the router will choose which protocol's route/routes to use. but i do not think the same ospf process will load balanc inside it. what if the EIGRP load balance,but the router decide to use the static or ospf route ?? and what if different ospf processes learn the same routes to the same destination i mean what the router will do then??(the concrete operations) what will the IOS do ? maybe at the time when we start the OSPF processes it will not permit us to overlap the same network address at all !! i am not sure about that. thanks Jason. J CCNP P.R.C Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73785&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
RE: multiple ospf processes & route insertion [7:73727]
At 6:49 PM + 8/12/03, Zsombor Papp wrote: >So you want to solve a traffic engineering problem with MPLS/TE, huh? How >boring... :) Hey, if you can't take a joke in this business... > >Howard C. Berkowitz wrote: >> >> I freely admit that I've lost the sense of the problem that >> actually >> needs to be solved, with all the discussion of the various >> tables. >> Before my brain started to reboot, however, it sounded like it >> was a >> traffic engineering problem. Has anyone looked at the OSPF >> Traffic >> Engineering extensions here? >> >> Also, I got an impression that people didn't want to use MPLS >> for a > > TE problem. Why? That's essentially what it's for. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73946&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
RE: multiple ospf processes & route insertion [7:73727]
I freely admit that I've lost the sense of the problem that actually needs to be solved, with all the discussion of the various tables. Before my brain started to reboot, however, it sounded like it was a traffic engineering problem. Has anyone looked at the OSPF Traffic Engineering extensions here? Also, I got an impression that people didn't want to use MPLS for a TE problem. Why? That's essentially what it's for. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73928&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
RE: multiple ospf processes & route insertion [7:73727]
hi guys, how about if the advertising router has received an update to one of those same prefixes, how does it know which is which. thanx Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73881&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
RE: multiple ospf processes & route insertion [7:73727]
What is "advertising router" and what are "those same prefixes"? And where does it learn them from? Otherwise it's clear... :) Thanks, Zsombor amer kulaif wrote: > > hi > > guys, how about if the advertising router has received an > update to one of those same prefixes, how does it know which > is which. > > thanx Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73905&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
RE: multiple ospf processes & route insertion [7:73727]
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
RE: multiple ospf processes & route insertion [7:73727]
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
RE: multiple ospf processes & route insertion [7:73727]
Jason J wrote: > > Fred is right > all routes from different routing protocals will be put > into route table ,but!! even if they are the same ! Would be surprising. IMHO one route (meaning a prefix+mask combo) can be installed only by one routing process. Can you post some 'show ip route' output that shows otherwise? > and what i mean in the last article is the "ospf routing > table", not route table.even there can be more same network > link in its ospf database. > > the router will choose which protocol's route/routes to use. > but i do not think the same ospf process will load balanc > inside it. So what do you suppose would happen if there are multiple equal cost routes to the same destination? Every reasonable routing protocol can do load-balancing, I am surprised that anyone would doubt that OSPF can do it, too. > what if the EIGRP load balance,but the router decide to use the > static or ospf route ?? If the router decided to use the static or OSPF route, then obviously the EIGRP route(s) won't play any role. > and what if different ospf processes learn the same routes to > the same destination i mean what the router will do then??(the > concrete operations) See my first post in this thread. > what will the IOS do ? maybe at the time when we start the > OSPF processes it will not permit us to overlap the same > network address > at all !! i am not sure about that. You can't put the same interface into multiple OSPF processes but that doesn't mean that the two processes can't learn about the same network. Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73787&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
RE: multiple ospf processes & route insertion [7:73727]
No, I don't think there will be any load balancing even in the same ospf processes. thanks Jason J CCNP P.R.C Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73784&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
RE: multiple ospf processes & route insertion [7:73727]
Dear Zsombor: "You can't put the same interface into multiple OSPF processes but that doesn't mean that the two processes can't learn about the same network." if you can't learn put one interface into multiple OSPF processes, then except you redistribute the direct donnected and static, how could they learn the same address ,learn from each other? i think the same condition exist on other routes ,how could a network link's status be share with other ospf process without put the sme interface into multiple OSPF processes? best regards Jason J CCNP P.R.C **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=73845&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
RE: multiple ospf processes & route insertion [7:73727]
O.K., no problem, everyone makes mistakes, and that was a pretty easy one to make. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Jason J [mailto:[EMAIL PROTECTED] Sent: Sunday, August 10, 2003 3:04 AM To: [EMAIL PROTECTED] Subject: RE: multiple ospf processes & route insertion [7:73727] er.Sorry about that! I Think i make a mistake, I did no see two same routes from two different routing protocols. in fact, one is "61.168.0.0",another is" 161.168.0.0" . really sorry for put so much trouble on you. everything comes from my experiments's wrong result. the wrong result comes to the wrong conclusion. so ,really thanks a lot , Zomber and Fred. for pointing out my mistake, so i can get a chance to learn more. Jason.J CCNP P.R.C **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=73805&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
RE: multiple ospf processes & route insertion [7:73727]
O.K., no problem, everyone makes mistakes, and that was a pretty easy one to make. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Jason J [mailto:[EMAIL PROTECTED] Sent: Sunday, August 10, 2003 3:04 AM To: [EMAIL PROTECTED] Subject: RE: multiple ospf processes & route insertion [7:73727] er.Sorry about that! I Think i make a mistake, I did no see two same routes from two different routing protocols. in fact, one is "61.168.0.0",another is" 161.168.0.0" . really sorry for put so much trouble on you. everything comes from my experiments's wrong result. the wrong result comes to the wrong conclusion. so ,really thanks a lot , Zomber and Fred. for pointing out my mistake, so i can get a chance to learn more. Jason.J CCNP P.R.C **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 **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=73824&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
RE: multiple ospf processes & route insertion [7:73727]
I haven't read the rest of the replies to this yet, but I think there is some confusion (probably on my part reading the post I replied to). The post I replied to talked about "putting into the [OSPF] routing table." If there is a static and a BGP route, the router should put both into the active router table, right? Now, what route the router chooses when actually routing packets is of course the most specific first, and then the one with the lowest administrative distance. That's what I said in my reply, that the router would put both static and BGP route in the routing table. I didn't make any statement on what route a router should choose when routing packets... I guess I got thrown because the original post was talking about multiple OSPF processes and what route would get inserted into the routing table, and then the subject was changed mid-way to what route in the routing table a router should choose. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Jason J [mailto:[EMAIL PROTECTED] Sent: Saturday, August 09, 2003 10:36 AM To: [EMAIL PROTECTED] Subject: RE: multiple ospf processes & route insertion [7:73727] Dear Fred in fact, 192.168.0.0/18 does include 192.168.0.0/19 and 192.168.32.0/19.wherenever router choose route, it will always pick the most concrete one so even 192.168.0.0/18 is static, it will choose the one from EBGP, 192.168.0.0/19. when the route from EBG is 192.168.0.0/18 and there is static route 192.168.0.0/18, sure the router will choose the static one. Jasong.J CCNP P.R.C **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=73790&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
