Re: NAT on a Trident/Qumran(/or other?) equipped whitebox?

[joel jaeggli <joelja () bogus com>]

On 10/16/18 08:55, Brandon Martin wrote:
> On 10/16/18 10:05 AM, James Bensley wrote:
> > NAT/PAT is an N:1 swapping (map) though so a state/translation table
> > is required to correctly "swap" back the return traffic. MPLS for
> > example is 1:1 mapping/action. NAT/PAT state tables tend to fill
> > quickly so to aid with this we also have timers to time out the
> > translations and free up space in the translation table, and also
> > track e.g. TCP RST or TCP FIN to remove entries from the table, so
> > it's not "just swapping".
>
> I do wonder, though, if these popular switching ASICs are flexible
> enough in terms of their header matching and manipulation capabilities
> to handle packet mangling and forwarding in hardware for a given NAT
> state entry while punting anything that requires a state change to a CPU
> for inspection and state update.
>
> You'd need a somewhat more powerful CPU than your typical L3 switch
> might have, but it seems like you'd still be able to offload the vast
> majority of the actual packet processing to hardware.

This is a flow cached router fundamentally. They exist. In that design
you burn your fib on flow entries rather than on nexthop routes. They
tend to explode at forwarding rates far lower than a typical ethernet
switch when their ability to accumulate new state is exercised.
riverstone RS circa 1999-2004 and various cisco products (sup 1a cat6k?)
did follow that model.

> State table size (on a typical "switching" ASIC) might be an issue
> before you could actually fill up a 10Gbps+ link with typical SP
> multi-user traffic flows, I guess, and given that a moderate-spec PC can
> keep up with 10Gbps without much issue these days, maybe it's a
> non-starter.

Attachment: signature.asc
Description: OpenPGP digital signature