[f-nsp] CAM limit on MLX

[Mike Allen]

Alex, there are a couple of reasons.  The mgmt module sets the
'personality' of the chassis.  Brocade is working towards a more universal
module, which is then license-able up for more capabilities.  This will
eventually simplify sparing, testing, etc.  To get back to the original
discussion, there are -M and -X line cards.  If you have a -M mgmt module,
then you can use either -X or -M line cards, and they will revert down and
function to the -M or MLX specs.  If you have a -X mgmt module, then only
-X modules will work, -M modules will not boot.  The MLX or -M have a lot
of uses, typically as enterprise or DC core, so the lower route's/CAM, etc,
are not a factor, and it allows customers to save money.

Mike

On Mon, Feb 11, 2013 at 4:05 PM, Alex HM <alex.hm.list at gmail.com> wrote:

> Thanks Mike.
>
> Yes indeed, very helpful.
>
> Maybe for the record, why would anybody choose BR-MLX-MR2-X over
> BR-MLX-MR2-M? They seems to price comparably.
> I got told offlist that the X has twice the CAM capacitify of the X, but
> both work fine. Only drawback, if any blade in the chassis is not X then
> the X card will work as an M card.
>
> Since I question everything, I just would like to get this confirmed. Is
> that accurate? If yes, why would anybody pick an M rather than an X?
>
> Thanks
> --- Alex
>
>
> 2013/2/12 Mike Allen <mkallen at gmail.com>
>
>> Hi, as mentioned by the other guys, CAM=FIB, and is 1M v4 routes per
>> 'tower' on the line card. There are two towers on most of the 10g modules,
>> a single tower on the 1 gig modules.  Each tower is 2 or 4 ports (4 or 8
>> port module, respectively).  This is on the -X, or XMR modules.  The -M, or
>> MLX modules are half that.  Once you start dividing up the cam for v6, the
>> math changes quickly, since v6 entries take up 4 times as much as a v4
>> entry.
>>
>> For RIB, the MR is capable of 10M routes, it has 2GB SDRAM.  The MR2 is
>> twice as much memory, and will support up to 15M routes.  The RIB handles
>> v4 and v6 routes differently than the CAM, and thus does not have the same
>> loss for integrating v6 routes, they are handled much the same with similar
>> numbers.
>>
>> Hope that helps.
>>
>> Mike
>>
>>
>> On Mon, Feb 11, 2013 at 2:31 PM, Alex HM <alex.hm.list at gmail.com> wrote:
>>
>>> Thanks Jay, Niels.
>>>
>>> I can’t find any figures on the capabilities of the MLXe with
>>> BR-MLX-MR2-M management card regarding RIB and/or FIB, thus my concern. Attached
>>> is an extracted table from a CER presentation. I have no clue how these
>>> figures reads as they are crude figures – the datasheet of the MLX mentions
>>> 10M BGP routes but it also state depending on the configuration, so I don’t
>>> take this one for granted.
>>>
>>> Although not my primary question, I'd be very keen on aggregating as
>>> many prefixes as possible, especially the polluting /24, since most of
>>> these small networks who usually de-aggregate are doing that on the sole
>>> purpose of tiering their traffic commits for $ reasons. AFAIK it takes
>>> hundreds of hand-written statements and RIR records processing to achieve
>>> that. If somebody has a hit for that too, I am a buyer :-)
>>>
>>> --- Alex
>>>
>>>
>>> 2013/2/11 Niels Bakker <niels=foundry-nsp at bakker.net>
>>>
>>>> * alex.hm.list at gmail.com (Alex HM) [Mon 11 Feb 2013, 22:51 CET]:
>>>>
>>>>  I am considering running 8 eBGP sessions with full-route on each
>>>>> (approx. 3'500'000 prefixes expected). As far as I could figure out, the
>>>>> CAM limit depends on the CAM profile. The XMR seems to support 1M IPv4
>>>>> prefixes in ipv4 profile mode and 512K on MLX. These figures are according
>>>>> to "CAM partition profiles" of the MLX Configuration Manual.
>>>>>
>>>>
>>>> Prefixes from your 8 eBGP sessions will form your RIB.  The best routes
>>>> are then placed into the FIB.  That's where you may hit CAM partitioning
>>>> limits.
>>>>
>>>> I'm not quite sure what the limit on RIB size is but 3.5M will fit just
>>>> fine memory-wise in an XMR Management Module.
>>>>
>>>>
>>>>         -- Niels.
>>>>
>>>> --
>>>> ______________________________**_________________
>>>> foundry-nsp mailing list
>>>> foundry-nsp at puck.nether.net
>>>> http://puck.nether.net/**mailman/listinfo/foundry-nsp<http://puck.nether.net/mailman/listinfo/foundry-nsp>
>>>>
>>>
>>>
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp at puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>
>>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20130211/985a93b3/attachment.html>