[f-nsp] CAM limit on MLX

[Alex HM]

Thanks Mike.


2013/2/12 Mike Allen <mkallen at gmail.com>

> 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/20130212/20cb4d33/attachment.html>