3

Do there exist any routing protocols which take link capacities and loads into account?

To illustrate the question, suppose there are are multiple paths between a source host A and a destination host B. OSPF will load-balance on a flow-by-flow basis if the paths are of equal cost, but if the links are of non-equal cost, OSPF will only load the lower cost link. More to the point, even in the equal-cost path case, OSPF does not take link loads from other source-destination pairs into account and so may still choose a (badly) sub-optimal assignment of flows to paths. We see that OSPF does not consider link capacity and load but only a static "cost".

9

Do there exist any routing protocols which take link capacities and loads into account?

There are two ways to handle the issues you describe:

  • MPLS TE w/ RSVP (complicated)
  • EIGRP (easier, but isn't so good out of the box)

MPLS TE w/ RSVP:

MPLS Traffic Engineering is not quite a routing protocol, but it adds the capability for OSPF or ISIS to calculate costs based on offered load using IGP extensions that are specific to MPLS-TE (OSPF Opaque LSAs or ISIS Sub-TLVs).

There are two normal ways of adjusting traffic based on the offered load along MPLS TE paths:

  • One is via what Cisco and Juniper call "automatic bandwidth adjustment" (Cisco doc / Juniper doc)
  • You can also use offline calculations for traffic optimization, and push policies to your MPLS TE nodes.

MPLS TE w/ RSVP reserves bandwidth along an entire path, and then each MPLS TE router can be configured to periodically announce updates and even enforce those bandwidth limits per-hop; Pete Templin's NANOG presentation has a pretty good overview of how this works. Some people say that Cisco doesn't enforce MPLS TE bandwidth constraints along the path; however, that's actually only part of the story. If you use Diffserv-aware TE (DS-TE), you can enforce bandwidth limits on tunnels (subject to platform / IOS support).

Closing note: your question described link loading problems, which MPLS TE certainly can handle; however, MPLS TE is more of a path-management framework. MPLS TE is meant to manage multiple paths between routers... with each path being more than one link.

EIGRP:

Certainly EIGRP has the capability to adjust IGP costs based on the offered load; however, this capability is disabled by default in EIGRP (for good reason). The command to enable it is metric weights, which uses this formula. The K2 parameter defaults to 0; when it's non-zero it will take Cisco's interface "load-average" parameter into consideration.

EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay) + (K5/(Reliability + K4)))

However, EIGRP won't send updates merely because the load-interval changes, it will only send an update when there is another topology change. The end result is that until there is a topology change, the local router will make decisions based on load; however, other routers won't be aware of those decisions until EIGRP is forced to send updates. Practically, this EIGRP load-average feature can solve some point problems, but isn't as helpful as MPLS TE in my opinion.

| improve this answer | |
2

EIGRP uses the load indicated by IOS as part of its calculations. EIGRP can also load-balance relatively appropriately on unequal cost paths.

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enhanced-interior-gateway-routing-protocol-eigrp/whitepaper_C11-720525.html

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.