RE: multiple ospf processes & route insertion [7:73727]

2003-08-14 Thread Reimer, Fred
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


RE: multiple ospf processes & route insertion [7:73727]

2003-08-14 Thread Reimer, Fred
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]

2003-08-14 Thread Reimer, Fred
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]

2003-08-14 Thread Jason J
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]

2003-08-14 Thread Jason J
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]

2003-08-14 Thread Zsombor Papp
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]

2003-08-14 Thread Zsombor Papp
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]

2003-08-14 Thread p b
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]

2003-08-14 Thread Zsombor Papp
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]

2003-08-14 Thread amer kulaif
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]

2003-08-14 Thread Howard C. Berkowitz
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]

2003-08-14 Thread Howard C. Berkowitz
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]

2003-08-14 Thread Zsombor Papp
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]

2003-08-14 Thread Reimer, Fred
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]

2003-08-14 Thread Zsombor Papp
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]

2003-08-14 Thread Zsombor Papp
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]

2003-08-14 Thread p b
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]

2003-08-14 Thread Jason J
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]

2003-08-14 Thread Jason J
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]

2003-08-14 Thread p b
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]

2003-08-14 Thread Zsombor Papp
"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]

2003-08-14 Thread Jason J
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]

2003-08-14 Thread Zsombor Papp
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]

2003-08-14 Thread Jason J
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]

2003-08-14 Thread Jason J
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]

2003-08-14 Thread Jason J
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]

2003-08-12 Thread Jason J
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]

2003-08-11 Thread p b
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]

2003-08-11 Thread p b
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]

2003-08-10 Thread Jason J
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]

2003-08-10 Thread Reimer, Fred
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]

2003-08-10 Thread Jason J
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]

2003-08-10 Thread Zsombor Papp
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]

2003-08-10 Thread Jason J
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]

2003-08-09 Thread Jason J
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]

2003-08-09 Thread p b
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]

2003-08-09 Thread Reimer, Fred
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]

2003-08-09 Thread Jason J
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]

2003-08-08 Thread Mark Johnson
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