[c-nsp] Scaling L2

T Johnson tjohnson46 at gmail.com
Thu Jan 13 21:45:44 EST 2011


Certainly you can throw more hardware at it, but eventually you still
run out of capacity. I think the vendors realize this which is why
things like TRILL are being developed. However, it seems like this
could be solved other ways as well. Unfortunately it sounds like
others aren't quite as concerned?

Thanks,
Thomas

On Wed, Jan 12, 2011 at 3:44 AM, Peter Serwe <peter.serwe at gmail.com> wrote:
> You need something bigger/better to aggregate on.
> Peter
>
> On Sun, Jan 9, 2011 at 4:12 PM, T Johnson <tjohnson46 at gmail.com> wrote:
>>
>> I have a virtualization environment that is quickly growing and I tend
>> to use "smaller" catalyst 2xxx and 3xxx series switches. One problem I
>> see coming up is running out of MAC address table space on these
>> switches as well as tons of L2 broadcast traffic.
>>
>> My question is this: does cisco have a way to deal with this when
>> you'd want to keep things in one L2 domain (rather than
>> forcing L3 boundaries)? I see the TRILL/fabricpath stuff, but of
>> course it only runs on switches I don't have the budget for.
>>
>> Dreaming up things... it would seem fairly easy if I could just
>> "route" sets of MAC addresses out to different connected switches.
>> It's fairly easy to assign MAC addresses on the server side to help
>> support
>> this. Anything like this possible? Or another solution?
>>
>> Thanks
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
> --
> Peter Serwe
> http://truthlightway.blogspot.com/
>



More information about the cisco-nsp mailing list