I have a scenario where 7604 is connected (upstream) to 7200 (downstream) over 2 Ethernet links. OSPF is configured over 2 ethernet links. Ethernet links are connected to the switch and terminated as sub-interfaces in single physical interface of 7604 and 7200.
Suppose say both the ethernet links are taken for 10 Mb each and the peak traffic to the downstream location is 16 Mb.
Now when the traffic flows from upstream to downstream it is not getting load shared evenly over 2 ethernet links. One ethernet link carries 10 Mb and other one carries 6 Mb. Thus traffic flowing on first ethernet faces heavy packet drops.
But OSPF cost for 2 ethernet links are same and routing entry to the downstream's loopback shows 2 ethernet links in upstream (traffic always flow to the downstreams loopback).
Since 7604 is not supporting per packet load sharing configuration in interface, i m not able to configure it.
Is there any way that I can configure to have a distributed load sharing over 2 ethernet links.
Normally, CEF will round-robin traffic flows, so it's normal, at any instant, to see multiple links with different loads. If you configure CEF per-packet, it will round-robin individual traffic flow packets and link load balancing would be much better. Using per-packet, though, does risk your traffic to sequencing issues (although with only two like links, between two devices, likely minimal impact).
What's not clear, nor am I sure with a 7600, CEF per-packet might not be an offered option on LAN Ethernet ports (you didn't describe your Ethernet cards or sup). It (CEF per-packet) might be supported if you ran Ethernet off a WAN type module, i.e. FlexWAN or SIP-200/400.
Another possible option, I believe later IOS images for 7600s support a limited form of OER. OER can dynamically balance multiple flows across multiple links.
I do not agree on the minimal impact with only two links. All what it takes is one out of sequence packet to confuse and reset a PCs TCP session. That leads to retransmissions and more traffic ultimately.
The L3 switches do not offer per-packet load sharing in the attempt to conserve network's sanity.
It's amazing to see how people fails to grasp the above and this matter has to be discussed again and again.
"I do not agree on the minimal impact with only two links. All what it takes is one out of sequence packet to confuse and reset a PCs TCP session. That leads to retransmissions and more traffic ultimately. "
My understanding is an out-of-sequence TCP packet will generate a dup ACK, and that most TCP implementations look for 3 dup ACKs before considering a packet lost and retransmitting the "lost" packet.
So, with only two links, alternating packets, of equal bandwidth and delay, I wouldn't expect the out-of-sequence delivery to cause most TCP implementations a problem.
Other non-TCP traffic can also be, of course, packet sequence sensitive, but most will tolerate some since, by design, IP itself doesn't guarantee sequenced delivery. So, like TCP, all IP applications should tolerate some out-of-sequence delivery.
I do agree that most don't well understand this issue, and it's easy to hit the point where there's enought out-of-sequence delivery to cause a major performance problem. For that reason, most should avoid intentionally causing out-of-sequence delivery.
If you can provide a packet trace, or other documentation, where just one out-of-sequence TCP packet forced a PC TCP session to reset, I would be curious to know of it, the TCP stack version, and its configuration, that showed such behavior.
I don't have the traces, and I do not debate theoretically. But, I've seen it happening.
I invite anyone that wants to learn networking, to do a proper test himself, with and without concurrent traffic, looking at transfer rates, total packets sent, etc.
Usually the amount of stuff learned, not necessarily in the specific matter, is worth the effort.
I don't doubt you've seen it happen. However, learning networking via testing, without knowing theory, can often mislead. Knowing theory, and obtaining expected results, might just be "lucky".
Knowing theory, and obtaining unexpected results, is when you really learn. Either you really don't know the theory or you've found an environment problem.
"I've found that theoretically inclined people is often poor at real networking, as they often disconnect from the true state of things. "
Hmmm, never had the chance to work with a good engineer then? I realize they often are in very short supply. Perhaps you've only encountered those that think about the science, not the practical application. Or, perhaps you've only encountered those afraid to put their "posterior" on the line for a working system.
As there's a real difference between an engineer and a scientist, there's also a real difference between an engineer/architect and a mechanic/technician in their outlooks. However, I'm not one to knock other outlooks, because all have their usefulness when properly utilized.
I did had many chances of meeting good engineers, especially during my long tenure at cisco. And some poor one also.
Coherently with my attitude, let me put this in a very practical way.
I could not care less about labels like engineer/scientist/technician/architect, although I'm well aware of their supposed meaning.
I'm in this industry since more than 20 years now, and I've found that the "best" people at designing and running networks have an humble personality, are willing to get their hands dirty with practicalities, put practice before theory and that do not put a tile before the name. A reputation perhaps, but never a title.
Instead, often I've seen that people with heavy theoretical background, have issues learning quickly, retaining knowledge, and maintaining feet on ground. Perhaps they became consumed by the long years spent on books.
That is my experience and opinion, then anybody is entitled to differ from me.
(BTW, apologies to original poster, and other readers, as Paulo and I go off beyond original question.)
I agree there are good and bad people doing almost anything, including networking. I also agree many of the traits you note are indeed attributes of a good practitioner. I also agree about position titles, although I was discussing outlooks; a different thing. There can be a major difference between a title, such as "network engineer", and whether that person has an engineering outlook.
At least to me, you seem to be implying theoretical knowledge is an impediment to providing a functional and practical network, and perhaps that's been your experience. (From what you descibe, regardless of position titles, it sounds like you've had experience with scientist outlooks, not engineer outlooks. The essense of engineering is turning science into practice.)
My experience, this month 30 years, has all been within businesses delivering or correcting production systems. Personally, haven't often had the chance to work, with what we used to call, "Ivory Tower" types, instead, most often work with "trade school" folk. I.e. those with no formal education within the field besides what they learn on-the-job or perhaps while pursuing a certificate. There's nothing wrong, I believe, entering the IT profession without formal study in the field, but if they really want to be an "engineer", in more than title, I think at least some theoretical knowledge is another important and necessary attribute of a good practitioner.