What is everyone using for an OSPF cost formula that factors in a circuits delay and bandwidth (10M-100G)???
Thanks in advance
umm..are you sure your question is not about EIGRP?
OSPF has no concept of interface-delays.
The default reference bandwidth for OSPF is 100M
In your case if you set your reference bandwidth to 100000 your 100G links would have a link cost of 1, 10G - 10, 1G-100, 100M-1000 and 10M-10000
A vendor specific list would be a better place to ask.
./Randy
I understand OSPF default calculation for cost doesn't include delay. I am looking for a formula that I can use to manually set the OSPF costs that factors in delay.
When using OSPF's default costs, the shortest path is not always the optimal path.
Example
New York to Los Angeles. Assuming all links are the same bandwidth and have a ospf cost of 1.
Path 1 (75ms) - OSPF Cost 2 - New York > Dallas > Los Angeles
Path 2 (65ms) - OSPF Cost 3 - New York > Chicago > Denver > Los Angeles
If I left the default cost's alone then path 1 would win because it has a lower ospf cost, however it take traffic 10ms longer to get there.
However I would like traffic to take Path 2 by adjusting the OSPF cost.
I am looking for a formula that other people are using .p
Thanks
Erik
Some networks I have worked with took the average latency of each link and assigned that (with some constant multiple) as the interface cost.
Of course this all fails miserably if you are using anything like MPLS underneath your OSPF.
Owen
Some networks I have worked with took the average latency of each link and
assigned that (with some constant multiple) as the interface cost.Of course this all fails miserably if you are using anything like MPLS
underneath your OSPF.
But then when using MPLS underneath, then MPLS Traffic Engineering can be
used to do some interesting path computations and resiliency configurations.
Eric,
Issues:
1.OSPF (SPF) can only produce a SPT based on cost (metric).
Anything else would require CSPF rather than SPF.
2. Delay is not distributed as part of an IGP update
Typical constrains distributed are: bandwidth, color, some others
In IETF we are working to also be able to distribute those kinds of
metrics (draft-ietf-ospf/isis-te-metric-extensions)
draft-ietf-mpls-te-express-path defines how to use these metrics for
RSVP-TE (computation result is an ERO) however theoretically nothing
precludes one (implementation) to use those for more comprehensive
computation, i.e. delay could be taken into consideration as long as the
path is loop free. So it would look like - compute all loop free paths to
a destination and then choose one with the smallest cumulative delay.
BTW - segment routing will give you this functionality day one 
Cheers,
Jeff
I wasn’t attempting to promote or discourage use of MPLS. I was merely endeavoring to point out that in an MPLS world, OSPF costs are not how you want to manage your traffic.
Owen
Eric,
Issues:
1.OSPF (SPF) can only produce a SPT based on cost (metric).
Anything else would require CSPF rather than SPF.
A CSPF based protocol would be a suitable algorithm for adding hard
constraints, instead of preference, such as path delay must be less than X,
instead of just a weight for each edge of the graph.
However, if you like: you can use a manually set cost for every link
------- manually figure a weight based on bandwidth or delay at ideal
utilization (but not both delay and bandwidth simultaneously).
For example, if you equate cost to delay, then you might decide that the
greatest delay any path through your AS/routing domain should ever see,
from any pair of routers end-to-end is 120 milliseconds.
Then you can scribble that down, and figure out what fraction of 120ms
the delay for every IGP link is, under ideal conditions, to set your
weight to the corresponding fraction of your chosen maximum weight.
Then decide on a reference scale, for example: 100% = cost of 16384
Within that model, a link with 120 milliseconds delay, traversing that
link costs 16384.
Traversing a link with 10 milliseconds delay should have cost 1366, etc.
Over multiple hops, the costs will then sum together, to give delay under
idealized conditions.
2. Delay is not distributed as part of an IGP update
Typical constrains distributed are: bandwidth, color, some others
[snip]
RSVP-TE (computation result is an ERO) however theoretically nothing
precludes one (implementation) to use those for more comprehensive
computation, i.e. delay could be taken into consideration as long as the
path is loop free. So it would look like - compute all loop free paths to
a destination and then choose one with the smallest cumulative delay.
What I would like to see is dynamic computation of Delay and Utilization.
Instead of merely "choose the one with the smallest cumulative delay" -----
choose the one with the smallest cumulative delay, BUT, offer load
balancing over the N lowest delay links in proportion to the available
utilization.
For instance... if one of the paths has a link somewhere in it is that
90% congested, load balance unequally, and send a majority of packets over
the path with the maximum 25% utilization, that has less than 10% in
additional delay.
BTW - segment routing will give you this functionality day one 
The auto-cost capability in some vendors devices seems to have left many
people ignoring the link metrics within their IGP. From what I recall in
the standards - bandwidth is one possible link metric but certainly not
the only one. Network designers are free (and I would encourage to) pick
whatever metric is relevant to them.
I am looking for a formula that other people are using .p
I've started to use a combination of 3 metrics to determine my costing:
* The traditional auto-cost calculation based on a 100Gbps reference
which gives far more useful values than the old 100Mbps reference.
* An average or nominal link latency multiplied by a factor of 200.
Sometimes adjusted if I want two geographically diverse paths between
the same endpoints to have equivalent costs.
* Path length in km multiplied by 2. This accounts for situations when
the nominal latency is too small to accurately determine and assumes 1
ms per 100 km.
I then pick the largest of the above 3 metrics as my OSPF cost.
Specifically, fails miserably if you use RSVP-TE to build
your MPLS backbone.
LDP follows IGP cost (has to be manually enabled in Junos),
so no issues there if your MPLS domain is LDP-signaled.
Mark.
Again, only an issue when using RSVP-TE.
I'd recommend MPLS-TE (especially core-to-core, as that is
more scalable) when looking at making more aggregate routing
decisions when dealing with a bandwidth vs. latency
conundrum.
Adjusting IGP costs in favour of latency works well, but can
have pile-on effects behind or in front of the links being
worked on, which can be confusing to troubleshoot when
taking other PoP-specific factors into account. It also
obliterates any sane cost-assignment mechanism you might
have developed (or at best, makes it overly complex).
There is room for both options, typically depending on
network size, number of links, rate of topology change in
your network and skill level of your network engineering
team.
Mark.
The auto-cost capability in some vendors devices seems to
have left many people ignoring the link metrics within
their IGP. From what I recall in the standards -
bandwidth is one possible link metric but certainly not
the only one. Network designers are free (and I would
encourage to) pick whatever metric is relevant to them.
I think hard-coding cost on every link is better than
relying on automatic application of the same by the IGP.
Folk that use IS-IS have had to do this since the beginning.
But given OSPF implementations support the manual setting of
cost as well, you get the same benefits.
* The traditional auto-cost calculation based on a
100Gbps reference which gives far more useful values
than the old 100Mbps reference.
We use a reference bandwidth of 1Tbps, and manually
calculate cost based on that. Admittedly, in 2014, bandwidth
is probably less of a useful metric than latency, given
10Gbps links are "relatively" easy to get if you take the
global capacity average into account, as well as the
proliferation of CDN edge extensions and the data-centre-of-
things rampage going on at the moment.
* An average or nominal link latency multiplied by a
factor of 200. Sometimes adjusted if I want two
geographically diverse paths between the same endpoints
to have equivalent costs.* Path length in km multiplied by 2. This accounts for
situations when the nominal latency is too small to
accurately determine and assumes 1 ms per 100 km.
We are toying with a couple of models for doing this
scalably in the IGP. The idea is to find a model that is as
generic as possible, and doesn't take too many environmental
considerations into account, but allows for them at a mid
level. It is also equally important to use a model which
will survive staffing churn and ease training/understanding,
particularly in multi-vendor networks.
Of course, in the worst of cases, MPLS-TE will be deployed
to smoothen all of this out; and in fairness, barring any
major developments in IS-IS and OSPF, may be the most
scalable solution until SR (Segment Routing) takes hold.
I hope to report back, say in a year from now, once the dust
settles.
Mark.
+1
A path to a destination must be loop free, irrespectively.
So it is not a combination of multiple but rather a list of loop free paths to a destination where any other metrics are used as tie-breakers.
Another story - how do you get all that state distributed, inter-area cases, how do you make it actually useful ( LSDB vs TED ) and not to forget - FEC definition.
Regards,
Jeff