Re: Ethernet switch flooding packets?

On 12 Feb, 05:14, "anwarmahmoo...@xxxxxxxxxxxxxx"
<anwarmahmoo...@xxxxxxxxxxxxxx> wrote:
On 11 Feb, 23:01, Rick Jones <rick.jon...@xxxxxx> wrote:

Rick Jones <rick.jon...@xxxxxx> wrote:
Define "huge" :)  The PDF data*** for the 2610:
http://www.hp.com/rnd/products/switches/HP_ProCurve_Switch_2610_Serie....
http://www.hp.com/rnd/pdfs/datasheets/HP_ProCurve_Switch_2610_Series.pdf
suggests an 8000 entry MAC table.

BTW, a web search for "procurve mac table size" seems to be reasonably
effective at getting decent hits across the procurve family.

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Hi Rick,

Thanks for your reply.  I'm aware of the 8K address table, but I'm
being a little vague because I'm not part of the networks team and
don't have all the specifics;
 - I believe we use mainly 26xx at the edge, but I'm unsure what we
use at the distribution layer
 - I know roughly how many hosts we have on the main VLAN, but not
across all the (many and varied) secondary VLANs

Rick, is it normal and acceptable for a network to be flooding unicast
packets?  (I accept it's how it's designed, but didn't realised it was
OK)

Firstly:-
- a few leaked unicasts a second are of no concern to me at all.
- a network of 5000 hosts in a broadcast domain *is* of concern.
It is not *necessarily* incorrect and may be well designed
taking into acccount the known behaviour of the hosts and the
network equipment however it would be rather unusual to say the
least.

So:-
Yes it is OK to see some flooded unicast packets - in the sense that
it is
inevitable in some cases. It happens by design.

Some considerations with regard to the number of hosts in
a broadcast domain are -

Resultant 'background' broadcast level -verses-
- capacity of weakest device to process the 'unwanted' broadcasts
- capacity of slowest link to carry 'unnecessary' broadcasts

If you are using a network with spanning-tree controlled redundant
links then the behaviour when a link fails might be of concern. On
a topology change:
- Forwarding database (fdb) aging time is reduced to 15 seconds for
a
time.
- Switches may have to re-learn the whole fdb and switches have
a learning rate that may be dependent on the CPU. During
learning unknown unicasts are flooded. With such a large number of
hosts it may take some time to re-establish the fdb.


Finally:
Such a design is on current terms not normally 'good' practise
however without knowing much, much *much* more about it is
not possible to say whether the design is satisfactory or not. The
best measure of all of course is *does it work*.

My guess would be that if it does work every day then it has
been well designed. If such a network had been thrown together
there seems a decent chance to me that it might break from
time to time.

.

Loading