Force10 Gear - Opinions

Anton Kapela tkapela at gmail.com
Fri Sep 5 21:57:35 UTC 2008


On Fri, Sep 5, 2008 at 2:37 PM, Paul Wall <pauldotwall at gmail.com> wrote:
> Jo Rhett wrote:
>> Note the "not random" comment.  People love to use the random feature of ixia/etc but it rarely displays
>> actual performance in a production network.
>
> 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

Jo,

As Paul eludes, the measure of 'worth' today has moved from bits/sec
to one of 'operations per second' - where 'operation' could be many
different types of work. The 'ideal router' should be able to execute
administrative policy, scheduling, queuing, and of course, route
lookup and next-hop determination in as close to constant-time as
possible without regard for the packet or traffic composition. This
means that regardless the makeup or nature of the packet, the device
is able to do the same number of lookups with 10, 1000, or 1,000,000
routes in its FIB.

Commonly this is done through CAM and TCAM or in RAM using various
data structures that exhibit efficient traversal and lookup behaviors.
I would invite you to research these independently, as there is a
sizable body of work to review (ultimately this work is a class of
search/sort problem). Today we find most CAM based systems no longer
are interesting insofar as their raw forwarding performance; nearly
every feature that can be implemented in hardware will generally
exhibit the same scaling and performance behaviors as regular IP
forwarding. The same generally holds true for RAM-based systems,
though implementations vary by vendor (i.e. juniper IP-I/IP-II vs.
MX-series distributed CAM) and can preclude certain combinations of
work being performed on the packet during forwarding.

Bottom line: it's not bits/sec, it's ops/sec.

-Tk




More information about the NANOG mailing list