Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

ospf loadbalance

Hi all

My system network is running ospf update route .we have some branchs, The branch have 2 line leadline connect to HQ ,a line with bandwith 2Mb and a line with bandwith 4Mb

we had config run loadbanlance with cost ospf the same on 2 lines.but when anyline have perfomance not good , it will effect to performace of services.

pls help me tunning loadbalance of ospf

many thanks

3 REPLIES
Super Bronze

Re: ospf loadbalance

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

OSPF only supports equal cost load balancing.  So for OSPF you've done all you can by making the two paths appear equal.

If performance is poor when a link is congested, if you're not using any QoS, you might consider doing so.

If you devices support PIRO PfR, it can dynamically load balance across your two links.  I.e. it would "know" one path has 2x the bandwidth and it can maps flows to optimize the load balancing across both paths.  It also can load balance referencing different traffic classes.

If your hardware supports it, you might also experiment with compression.

If you budget allows for it, you might also consider WAAS.

Hall of Fame Super Silver

ospf loadbalance

The original poster might want to think about this aspect of what they are doing. When you manipulate the OSPF cost to make the links appear to be equal then OSPF will attempt to put approximately equal amounts of traffic on each link. This is likely to result in one link being over-utilized, suffering congestion, and perhaps dropping packets, while the other link is likely to be under-utilized.

It has been my experience that when you have two links that really are not equal in capacity that it is better to let OSPF choose the best path with the other path as a backup and then to use something like Policy Based Routing to send certain traffic over the secondary link. This way both links get used and the routing protocol is not being mislead about the links.

HTH

Rick

Super Bronze

Re: ospf loadbalance

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Rick raises a valid point!

In my experience, whether you want to treat two unequal links, in OSPF, as equal, depends on the disparity of bandwidths between them, the nature of your traffic, and the bandwidth of the paths relative to typical flow bandwidth.

In the situation where there's a large bandwidth disparity, you generally do want to do as Rick suggests, which is not treat the links as equal.  A good example would be a T1 and a T3.

In the situations where there's some bandwidth disparity, you may want to treat them as equal.  For example a T1 p2p vs. T1 ATM (ATM has less "data" bandwidth) or a MetroE FastEthernet (100 Mbps) vs. an OC1 or OC3.

As a rough rule, if the link with more bandwidth doesn't offer better than 2x the bandwidth, you might want to consider them equal.  Why 2x?  Well if you have two flows, in "theory" each's "share" of the the bigger is only half its bandwidth.

Again, I want to emphasis this is a very rough rule I've used and it works best if your traffic isn't extremely bandwidth (guarantee) sensitive.  I.e. you're just trying to "statistically" provide more bandwidth.

The situation Rick mentions, the lessor bandwidth path being congested and dropping packets, while the greater bandwidth path has available bandwidth, isn't limited to just paths with bandwidth disparity.  This also happens on Etherchannel or other statically equal bandwidth paths, yet we often use those to "statistically" provide more bandwidth too.  I.e. at some points in time, you'll have less than ideal usage of your equal bandwidth links.

For unequal bandwidth paths, if the bandwidth disparity between unequal paths isn't too much, its overall behavior is sort of similar to equal cost especially over longer time intervals..

Depending on your service requirements, QoS might better manage one path's congestion (even when there's bandwidth available on the other path - also true for equal cost paths).

If PfR is used to load balance, your multiple links can be dynamically loaded to optimize their bandwidth.  This utilizes bandwidth more like MLPPP usage or packet-by-packet (latter generally to be avoided) type of bandwidth utilization.

Even with PfR, you still have the question do you set the routing metrics as equal or unequal.  PfR will dynamically balance both, but again as a rough rule, if the disparity is more than 2x, I set the links unequal, otherwise I set them equal.

Once again, whether you use PfR or not, you need to understand your traffic and its service requirements.  One size doesn't fit all, but the 2x disparity rule I'm suggesting, seems to work out well much of the time.  As OP's mentioned 2 Mbps vs. 4 Mbps, I would often treat them as equal, even without something like PfR, to try to leverage the additional bandwidth.

PS:

BTW, Rick's suggestion using PBR to direct some traffic to the lessor bandwidth path is excellent!

224
Views
0
Helpful
3
Replies