From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Tue Aug 24 2004 - 17:46:27 GMT-3
At 10:41 AM -0700 8/24/04, Edwards, Andrew M wrote:
>It's a development lab for a real world situation. 8) So, yes, I can
>tweak on it!
It would help to understand the real-world problem you are trying to
solve, not that the real world has much to do with CCIE. :-(
Let me look at the technologies here from a more abstract point of
view. Routing protocols, especially BGP but reasonably about basic
IGPs, are not about traffic management. A better term, indeed, would
be "reachability protocol".
BGP will really just give you reachability. Given the existence of
policies in the real world, it's unreasonable to assume Internet BGP
will give you a "best" route.
IGPs do go a little further, in trying to give you an optimal path
based on a LOT of assumptions, such as unloaded interface bandwidth.
The idea of making them load-adaptive, however, has not proved to be
useful in practice.
IGRP could use utilization in computing the composite metric, but
that approach had fundamental problems. At the most basic, given two
paths to a destination, it would tend to oscillate between the two
paths. As it would avoid one path because that path was unloaded, the
alternate path would become more loaded, and eventually the formerly
heavily used path would become more preferred.
The other problem was that IGRP could only see the utilization and
bandwidth of directly connected subnets. That could result in your
taking a fast path to a neighboring router, whose next hop is a
congested 64 Kbps X.25 link.
There were some research attempts to develop "multipath" routing
protocols that considered end-to-end issues in path selection (e.g.,
OSPF-OMP and other work by Curtis Villamizor), but these did not
prove especially practical. It was a constant battle between
recomputing very often and getting route optimality.
Today, the general approach to ensuring load distribution at layer 3
is traffic engineering, variously with reservation and differentiated
services. There is also considerable work on load distribution at
layer 4 and above.
My observation would be that trying too hard to get the routing
protocols to distribute load may be a waste of effort. You can get
some basic things done, but, eventually, you need to look at QoS
features including RSVP, and perhaps QoS-enabled RSVP. Don't dismiss
PBR out of hand, but also remember that CEF source-destination hash
will tend to distribute by source as well as destination.
>
>-----Original Message-----
>From: James [mailto:james@towardex.com]
>Sent: Tuesday, August 24, 2004 10:37 AM
>To: Edwards, Andrew M
>Cc: ccielab@groupstudy.com
>Subject: Re: FW: distance command...
>
>
>Hi Andy,
>
>
>On Tue, Aug 24, 2004 at 10:20:58AM -0700, Edwards, Andrew M wrote:
>> I know that you can set distance between routing protocols. If I were
>
>> running two instances of OSPF and redistributing then that would do it
>
>> too.
>>
>> Just seems to me that we have used administrative distance to alter
>> routing tables before. And in this instance, it seems reasonable that
>
>> I want to alter the routing table based upon the routing sources
>> believability.
>>
>> Not to mention, I have not found a way to set even/odd subnet
>> preferences within a single OSPF domain via COST. If someone knows...
>
>> I'm all ears!
>>
>> Otherwise, considering AD as the route selector, I'm asking the group
>> if I am way off the mark here, or is my approach doable?
>
>Just out of curiosity, is this a lab environment, or a real world
>situation?
>
>-J
>
>
>--
>James Jun TowardEX
>Technologies, Inc.
>Technical Lead Network Design, Consulting, IT
>Outsourcing
>james@towardex.com Boston-based Colocation & Bandwidth
>Services
>cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
>www.twdx.net
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:48 GMT-3