At 08:41 PM 3/27/2007 +0200, Christoph Loibl wrote: >Hi! > >On Mar 27, 2007, at 8:01 PM, Ian Cox wrote: > >>At 07:28 PM 3/27/2007 +0200, Arnold Nipper wrote: >>>On 27.03.2007 17:51 Nick Griffin wrote >>> >>>>Let me rephrase, assume I have no reason. What would a selling >>>>point be? I >>>>cannot not find any good documentation regarding the memory. What >>>>enhancements does it provide, more CAM entries, things of that >>>>nature. >>>>Perhaps I just need more information on the card, to help >>>>understand the >>>>need for additional memory that what it ships with by default. >>> >>>IIRC this gives you more buffer for your line card. I.e. you will be >>>able to buffer up to 1 GB worth of traffic. >> >>Not it does not give you more buffering on the line card. The larger >>memory part is for the processor on the line card so it can hold >>large FIB tables. > >Do I get this right... The memory is just for the DFC enabled cards?
You need more memory on the DFC cards because they have software copies of the FIB, ACLs tables etc that are used to program the hardware. >So why is there such a large amount of memory on the CFC only cards? I would not call 256Mbytes exactly large. The local CPU has to program the port ASICs and retrieve statistics. There are nearly 100 counters per port, and MAC and PHY ASICs have hundreds of registers one must program. Then there is the fabric and bus interface ASICs that have hundreds more registers. The interface queues are built into the port ASICs and use SRAMs. Along with state machines for auto negotiation, ... With an SXE5 image approximately 64Mbytes is used. You can not easily buy 128Mbyte memory parts any more so that is why the 256Mbytes. >There is no special data to store on the CFC line-cards except the >interface queues (which seem to be somehow integrated into the >interface chips)? Interface queues on the ports on most switch platforms are done in DDR/QDR SRAMs, Reduced Latency DRAM (RLDRAM), FCRAM which are generally soldered to the board. Some designs even manage to fit the memory on the ASIC itself. >I am not really familiar enough with this routers/switches >architecture (but curious - as we plan to put some of those in >various places). Does CFC mean that the whole packets are sent from >line-card to the SUP and if the SUP-Engine decides that it should be >transmitted on a port of the receiving line-card the packet goes over >the backplane a second time? On the 6500, the CFC transmits the packet on the backplane bus once to the supervisor. All the ASICs attached to the bus see the packet and the supervisor PFCx sends back the instructions to rewrite the packet and which port(s) the packet is going out. If the packet is going out the same line card then it gets rewritten and sent out. The process in different platforms varies due to the way they are designed. The following link at the bottom describes how sup32 forwards packets on the bus. The Sup720 with CFCs is different in that only headers go the Supervisor, and if the packet stays on the same complex then it does not need to go across the switch fabric. If the packet has to go to a different card or a different fabric channel on the same card then it is sent across the fabric. http://www/en/US/products/hw/switches/ps708/products_white_paper0900aecd803e508c.shtml Ian > Or is just the header (whatever needed >for the forwarding decision) sent to the SUP-Engine, ... ? > >Stoffi > > >> >>>It much depends what your application is. If you have sercer >>>connected >>>to that linecard having more buffer might be a good idea. Having >>>connected routers you may not want yout switch to buffer too much. >>> >>> >>> >>>Arnold >>>-- >>>Arnold Nipper / nIPper consulting, Sandhausen, Germany >>>email: [EMAIL PROTECTED] phone: +49 6224 9259 299 >>>mobile: +49 172 2650958 fax: +49 6224 9259 333 >>>_______________________________________________ >>>cisco-nsp mailing list cisco-nsp@puck.nether.net >>>https://puck.nether.net/mailman/listinfo/cisco-nsp >>>archive at http://puck.nether.net/pipermail/cisco-nsp/ >>_______________________________________________ >>cisco-nsp mailing list cisco-nsp@puck.nether.net >>https://puck.nether.net/mailman/listinfo/cisco-nsp >>archive at http://puck.nether.net/pipermail/cisco-nsp/ > >-- >CHRISTOPH LOIBL ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >mailto:[EMAIL PROTECTED] |No trees were killed in the creation of this >message. >http://pix.tix.at |However, many electrons were terrible inconvenienced. >CL8-RIPE ++++++++++++++++++++++++++++++++++++ PGP-Key-ID: 0x4B2C0055 +++ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/