Force10 Gear

David Newman dnewman at networktest.com
Sun Sep 7 09:23:07 CDT 2008


Paul Wall wrote:

> Once upon a time, vendors released products which relied on CPU-based
>  "flow" setup. Certain vintages of Cisco, Extreme, Foundry, 
> Riverstone, etc come to mind. These could forward at "line rate" 
> under normal conditions. Sufficient randomization on the sources 
> and/or destinations (DDoS, Windows worm, portscans, ...) and they'd 
> die a spectacular death. Nowadays, this is less of a concern, as the 
> higher-end boxes can program a full routing table (and then some) 
> worth of prefixes in CAM.
> 
> Either way, I think it's a good test metric. I'd be interested in 
> hearing of why you think that's not the case. Back on topic, doing a 
> couple of gigs of traffic at line rate is a walk in the park for any 
> modern product billed as a "layer 3 switch". The differentiator 
> between, say, a Dell and a Cisco, is in the software and profoundly 
> not the forwarding performance.

Without disagreeing with your main point, there are still plenty of ways
to bring even very large boxes to near-zero forwarding rates:

1. Set IP options. A pair of Cat 6509Es using VSS can forward packets
without options at up to 770 mpps, but when packets have options the
maximum is more like 20 kpps. And that's a "high-speed" example; the
options forwarding rate is more like 0 pps with some other devices.
Silicon that forwards packets very fast is only good when header lengths
are fixed.

2. Use weak hashing algorithms. Some switches (names removed to protect
the guilty) hash on the low-order three bits of MAC address to decide
which of eight ASICs will forward a packet. I have heard of, but have
not tested, devices that use only three bits for making OSPF ECMP
decisions. Not surprisingly either technique can lead to lots of hash
collisions in routed environments.

3. Offer IP multicast. Maximum forwarding rates for multicast are rather
different than IP unicast with some vendors' implementations, and may be
affected by group count, mroute count and amount of replication.

dn






More information about the NANOG mailing list