Hi, CC: Phil Pennock at Demon, we were discussing this just the other day. Boudewijn wrote: | Actually, I am about 99% sure that those Extreme switches DO use asics+cam | for packet forwarding, and the whole problem is that not every destination | fits in that memory. Hence the caching solution, and the problem when | traffic keeps thrashing the cache. This is how I understood them to work, also. I'm not going to say too much about it at this point, but when I explained to Extreme folks what had happened to BIT wrt the Riverstones, they were in fact curious to see what my testbed would do to the Summit/Alpine/BlackDiamond (in that order) box. If and when I get around to an afternoon in their TAC/POClab, I'll ask them for permission to publish some 'third party results'. A careful preliminary estimation: Extreme will kick Riverstone butt, but they will not perform as well with wild L3 destinations as Cisco CEF or any Juniper. My results for Riverstone may not be flattering for them but tough luck with the shit they pulled in their aftersales 'efforts' (quote: you could always put them on ebay!). They are available on request. If anybody has an ESR/GSR left in a corner and would like to feed me coffee, I'd be very interrested in running the same test on that hardware (just as I will on Juniper and Extreme), to proove a point. | For contrast, see (for example) Cisco routers with CEF enabled. Most of | cisco's routers, and certainly all lower end, do not have special purpose | asics. | With CEF however, they DO have a fixed forwarding performance, indepedent | of previous packets' destinations. | (And certainly a lot faster than the rumored worst cases for some of the | L3 switches. Wasn't it about 5kpps on that riverstone thingy worst case ? ) Our SSR3000 maxed out at 13Kpps of UDP packets with 376 bytes of payload. The destination addresses of each packet varied with a (lousy) pseudorandom 32 bit number. | From what I can find, Juniper also does not use CAM for storing forwarding | tables, but normal DRAM and SRAM. Yes, and their IP2 processor (it's a middleway between a CPU and an ASIC) can perform several 'expensive' functions such as most specific matching and ipv4/ipv6 prefix hash lookups in constant time. This uses normal DRAM to store the tables in. AFAICR on JunOS, the frames themselves are split into 64 byte j-cells and stored in shared memory. Each incoming frame triggers a notification message to the IP2, who can then do $stuff with the packet, using its footprint already in shared memory and request an egress interface' ASIC to pick up the shattered frame and free its memory. Alternatively it can filter the packet or put it into one of N hardware WRED queues (can't remember N at the moment). The thing is, having enough fast memory to sustain 'line rate' on each interface, which can ammount to a lot with gigabit and POS cards. But in the long run, trust Juniper's statements on these matters and not mine ;) -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________