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 <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> 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 <[email protected]> >>> >>>> * [email protected] (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 >>>> [email protected] >>>> http://puck.nether.net/**mailman/listinfo/foundry-nsp<http://puck.nether.net/mailman/listinfo/foundry-nsp> >>>> >>> >>> >>> _______________________________________________ >>> foundry-nsp mailing list >>> [email protected] >>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>> >> >> > > _______________________________________________ > foundry-nsp mailing list > [email protected] > http://puck.nether.net/mailman/listinfo/foundry-nsp >
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
