[f-nsp] CAM limit on MLX

[Alex HM]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20130212/1338289d/attachment.html>