[Nlnog] Cisco?

[Pim van Pelt]

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                /--- \/            __________________