[161530] in North American Network Operators' Group
Re: [c-nsp] DNS amplification
daemon@ATHENA.MIT.EDU (Jared Mauch)
Tue Mar 19 13:58:35 2013
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAL9jLaYgcbTdsor5VyuBOQ7hLZiQ-Sk72yemzcFpcD0sVbyL+g@mail.gmail.com>
Date: Tue, 19 Mar 2013 13:57:35 -0400
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: "nanog@nanog.org Group" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>>=20
>> With enough thrust, pigs fly quite well. Landing can get messy =
though...
>=20
> 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
>=20
> 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)
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.
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.
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 :)
- Jared=
