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!
