On 27/01/2011 16:00, Brett Frankenberger wrote:
Of course he is.
It certainly adds extra resilience if you have an individual bearer link
failure. But it also not unreasonable to assume that adding links into a
LAG will increase its throughput. Unfortunately, this is often not the
case on lots of Cisco hardware - including sup720 based equipment.
Taking your example below, if you had an 8 port LAG and one of them failed,
this would drop you down to a 4 port LAG in terms of throughput. If you
aren't expecting it, this is astonishing behaviour and have pretty serious
consequences.
This wouldn't be so much of a problem if the restriction were well
documented by Cisco. Unfortunately, it's not - you have to dig to find it,
and then infer that the same restrictions in CatOS also apply to IOS. I
guess it's not something that Cisco like to make too much noise about.
Nick
With five links, assuming the traffic hashes evenly
across the 8 buckets, he effectvly has 4GBps of throughput available.
If one of the five links fails, he still has 4GBps of throughput
available.
With four links, assuming the traffic hashes evenly across the 8
buckets, he effectively has 4Gbps of throughput available. But if one
of the four links fails, then he'll hash at 3:3:2 and effectively have
2.67Gbps available.
In other words, the fifth link doesn't add any throughput benefit in
the "everything is working" case -- four or five active links offers
the same throughput -- but it offers a significant redundancy benefit.
With five links, loss of one link is no impact to cpacity; with four,
loss of one link is a 33% reduction in capacity.
-- Brett
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
