Thanks Mike.
2013/2/12 Mike Allen <[email protected]> > 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
