[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[c-nsp] DNS amplification

On Tue, Mar 19, 2013 at 1:57 PM, Jared Mauch <jared at puck.nether.net> wrote:
> On Mar 19, 2013, at 1:50 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
>> On Tue, Mar 19, 2013 at 1:45 PM, David Conrad <drc at virtualized.org> wrote:
>>> On Mar 19, 2013, at 10:12 AM, Christopher Morrow <morrowc.lists at 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.