[161533] in North American Network Operators' Group
Re: [c-nsp] DNS amplification
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Tue Mar 19 14:18:40 2013
In-Reply-To: <3F828001-B02C-44C8-B753-6703BD43CEA2@puck.nether.net>
Date: Tue, 19 Mar 2013 14:12:39 -0400
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Jared Mauch <jared@puck.nether.net>
Cc: "nanog@nanog.org Group" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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> wrot=
e:
>>> On Mar 19, 2013, at 10:12 AM, Christopher Morrow <morrowc.lists@gmail.c=
om> 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: Junip=
er)
you mean a vendor embeded in their current design? ok.
> We have had numerous performance issues that have been attributed to soft=
ware defects they haven't observed on their 'modern' hardware, but is visib=
le 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 p=
er-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. T=
hat may work if your scale is small, but when you're quite large the dynami=
cs 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 o=
f 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.
