Re: [c-nsp] DNS amplification

[Christopher Morrow <morrowc.lists () gmail com>]

On Tue, Mar 19, 2013 at 1:57 PM, Jared Mauch <jared () puck nether net> wrote:
> On Mar 19, 2013, at 1:50 PM, Christopher Morrow <morrowc.lists () gmail com> wrote:
>
> > On Tue, Mar 19, 2013 at 1:45 PM, David Conrad <drc () virtualized org> wrote:
> > > On Mar 19, 2013, at 10:12 AM, Christopher Morrow <morrowc.lists () gmail com> wrote:
> > > > There's nothing inherent in BGP that would not work with an
> > > > unconstrained growth of the routing table, right? You just need enough
> > > > bandwidth and interrupts to deal with updates.
> > >
> > > With enough thrust, pigs fly quite well.  Landing can get messy though...
> >
> > I was being serious... the current 'bgp unconstrained dies' problem
> > isn't such a problem if you have (today):
> >  4-8 cores
> >  16 gb ram
> >  ssd
> >  gigabit ethernet
> >
> > or as you'd call this, your desktop computer... trying to do this on a
> > 600mhz mips with 512mb ram is, clearly, a problem.  put modern
> > hardware to work and it gets simpler. Yes, the above addresses
> > getting/sending 'rib' data, it doesn't address programming a FIB, but
> > rethinking the programming of the fib a bit could, I bet, even get us
> > to a palatable point for a longer while, in a relatively short period
> > of time.
>
> Try telling this to a vendor that uses these common components (eg: Juniper)

you mean a vendor embeded in their current design? ok.

> We have had numerous performance issues that have been attributed to software defects they haven't observed on their 
> 'modern' hardware, but is visible in the prior generation or few back of routing engines.
>
> There's also the problem of fitting the data in the appropriate SRAM on a linecard which is very expensive on a 
> per-bit basis to purchase and on a per-watt basis to operate.  This is why some folks have TCAM based platforms, 
> which have their own tradeoffs.

right, these are design choices they made ~10 years ago and didn't
upgrade along with the problem space. I'm really saying that we almost
have to take a fresh slate look at the problem... 'if you could do
things again, without the constraints of what we have today'

> We all can't just forward with N*10GE interfaces in a x86_64 platform.  That may work if your scale is small, but 
> when you're quite large the dynamics change considerably.

sure thing.

> Also, a "modern router" might look like this:
>
> cisco ASR9K Series (Intel 686 F6M14S4) processor with 12582912K bytes of memory.
> Intel 686 F6M14S4 processor at 2134MHz, Revision 2.174
>
> vs
>
> Cisco 7206VXR (NPE-G1) processor (revision B) with 983040K/65536K bytes of memory.
> Processor board ID 23671962
> SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache
>
>
> Those that are confusing the two need to be sent to reeducation camp :)

yes, still all single threaded and single core and ... :( 32bit, woot
:( so constrained to some extent on max-memory and address space.

also, I don't think this is 'just that simple'... but the tools exist.